Trace:

Differences

This shows you the differences between two versions of the page.

--- rabbitmq [2015/12/08 11:37]
steve [Creating a Cluster]
+++ rabbitmq [2015/12/08 12:11]
steve [Creating a Cluster]
@@ Line 61: / Line 61: @@
 A cluster can be created with more than one node. You will first create one instance which will act as the primary node, and then additional ones after that. Any time that a node is added to a running cluster, it will remove all the data currently in the primary node.
-First, start rabbitmq as normal on the primary node:
+One thing that is interesting and may be different to the user, is that RabbitMQ does not contain the settings for the cluster a config file. The cluster itself keeps track of who the nodes are, so there are no special settings that need to be added in ''/etc/rabbitmq/rabbitmq.config''.
+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.
 <code>
@@ Line 67: / Line 73: @@
 </code>
-Get the erlang cookie of the primary node, and set it to the same value in the secondary node.
+When a node is first started, RabbitMQ will create unique cookie (or identifier) for that node at ''/var/lib/rabbitmq/.erlang.cookie''. For the two nodes to join together, the cookie must be the same on all nodes.
-On the primary node:
+RabbitMQ will generate one itself on first startup, or it can be set manually to another value if wanted.
+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>
-cat /var/lib/rabbitmq/.erlang.cookie
+pwgen 8 1 | tee /var/lib/rabbitmq/.erlang.cookie
+chmod 0600 /var/lib/rabbitmq/.erlang.cookie
+chown rabbitmq: /var/lib/rabbitmq/.erlang.cookie
 </code>
-Alternatively, set the cookie manually:
+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>
-Note that by default, RabbitMQ will generate its own cookie, and the file will not have an EOL. So, there are two options. You can set
+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>

Differences

Search

Toolbox