Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
rabbitmq [2015/12/08 11:46] steve |
rabbitmq [2015/12/08 11:57] steve [Creating a Cluster] |
||
---|---|---|---|
Line 62: | Line 62: | ||
In this example, there will be two nodes only. A primary node which will start as normal using the default configuration, and then a secondary node which will be added to the first, therefore creating a cluster. | In this example, there will be two nodes only. A primary node which will start as normal using the default configuration, and then a secondary node which will be added to the first, therefore creating a cluster. | ||
+ | |||
+ | The server hostnames used here are ''rabbitmq1'' and ''rabbitmq2''. | ||
First of all, start rabbitmq as normal on both of the nodes. | First of all, start rabbitmq as normal on both of the nodes. | ||
Line 74: | Line 76: | ||
One gotcha to be aware of is that the default cookie set will have no end-of-line for the string. Adding a new line will change the hash. In this case, it may be simpler to just create your own erlang cookie before starting the primary node. | One gotcha to be aware of is that the default cookie set will have no end-of-line for the string. Adding a new line will change the hash. In this case, it may be simpler to just create your own erlang cookie before starting the primary node. | ||
+ | |||
+ | The permissions are also set to read-only for the rabbitmq user. | ||
+ | |||
+ | In this example, I use pwgen to create a random password as well: | ||
<code> | <code> | ||
pwgen 8 1 | tee /var/lib/rabbitmq/.erlang.cookie | pwgen 8 1 | tee /var/lib/rabbitmq/.erlang.cookie | ||
chmod 0600 /var/lib/rabbitmq/.erlang.cookie | chmod 0600 /var/lib/rabbitmq/.erlang.cookie | ||
+ | chown rabbitmq: /var/lib/rabbitmq/.erlang.cookie | ||
+ | </code> | ||
+ | |||
+ | At this point, the primary node is up and running, the cookie exists, and it is ready to have a second node joined to it to create a cluster. | ||
+ | |||
+ | On the second node, the RabbitMQ service is already running as normal, from when we started it earlier. Now, we need to tell rabbitmq to stop the application -- not the service -- so that we can join it to the primary node. | ||
+ | |||
+ | Stop the app on the second node: | ||
+ | |||
+ | <code> | ||
+ | rabbitmqctl stop_app | ||
+ | </code> | ||
+ | |||
+ | Next, edit the ''/var/lib/rabbitmq/.erlang.cookie'' value on the secondary node as well. | ||
+ | |||
+ | Join the secondary node to the first, creating the cluster. This will flush the data on the primary node as well: | ||
+ | |||
+ | <code> | ||
+ | rabbitmqctl join_cluster rabbit@rabbitmq1 | ||
+ | </code> | ||
+ | |||
+ | <code> | ||
+ | Clustering node 'rabbit@rabbitmq2' with 'rabbit@rabbitmq1' ... | ||
+ | ...done. | ||
+ | </code> | ||
+ | |||
+ | Finally, start the app again using ''rabbitmqctl'' on the second node: | ||
+ | |||
+ | <code> | ||
+ | rabbitmqctl start_app | ||
+ | </code> | ||
+ | |||
+ | You can check the status of the cluster as well: | ||
+ | |||
+ | <code> | ||
+ | rabbitmqctl cluster_status | ||
+ | </code> | ||
+ | |||
+ | <code> | ||
+ | Cluster status of node 'rabbit@rabbitmq2' ... | ||
+ | [{nodes,[{disc,['rabbit@rabbitmq1','rabbit@rabbitmq2']}]}, | ||
+ | {running_nodes,['rabbit@rabbitmq1','rabbit@rabbitmq2']}, | ||
+ | {partitions,[]}] | ||
+ | ...done. | ||
</code> | </code> |