Я запускаю RabbitMQ на 3 серверах, одна и та же версия Erlang и RabbitMQ: RabbitMQ 3.4.1, Erlang 17.3
На сервере 2 произошел сбой одного узла. Два других узла не подключились друг к другу:
сервер 1:
[CentOS-62-64-minimal ~]$ sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@CentOS-62-64-minimal' ...
[{nodes,[{disc,['rabbit@CentOS-62-64-minimal',rabbit@de3,rabbit@mysql]}]},
{running_nodes,['rabbit@CentOS-62-64-minimal']},
{cluster_name,<<"rabbit@CentOS-62-64-minimal">>},
{partitions,[]}]
сервер 3:
[de3 ~]$ sudo rabbitmqctl cluster_status
Cluster status of node rabbit@de3 ...
[{nodes,[{disc,['rabbit@CentOS-62-64-minimal',rabbit@de3,rabbit@mysql]}]},
{running_nodes,[rabbit@de3]},
{cluster_name,<<"rabbit@CentOS-62-64-minimal">>},
{partitions,[]}]
После перезапуска и сброса rabbitmq на сервере 3 он наконец подключился к server1:
[CentOS-62-64-minimal ~]$ sudo rabbitmqctl cluster_status
Cluster status of node 'rabbit@CentOS-62-64-minimal' ...
[{nodes,[{disc,['rabbit@CentOS-62-64-minimal',rabbit@de3,rabbit@mysql]}]},
{running_nodes,['rabbit@CentOS-62-64-minimal']},
{cluster_name,<<"rabbit@CentOS-62-64-minimal">>},
{partitions,[]}]
Почему кластер "сломался", когда вышел из строя всего 1 узел? сервер 3 работал нормально, а сервер 1 - нет: «Очередь находится на неработающем сервере».
Что касается сервера 2, он не перезагружался. После ручного перезапуска я не могу заставить его повторно подключиться к кластеру даже после многократного сброса и удаления / var / lib / rabbitmq / mnesia /:
[root@mysql ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@mysql ...
[{nodes,[{disc,[rabbit@mysql]}]},
{running_nodes,[rabbit@mysql]},
{cluster_name,<<"rabbit@mysql.domain.com">>},
{partitions,[]}]
[mysql ~]# rabbitmqctl stop_app
Stopping node rabbit@mysql ...
[root@mysql ~]# rabbitmqctl force_reset
Forcefully resetting node rabbit@mysql ...
[ysql ~]# rabbitmqctl join_cluster rabbit@CentOS-62-64-minimal
Clustering node rabbit@mysql with 'rabbit@CentOS-62-64-minimal' ...
Error: {ok,already_member}
[mysql ~]# rabbitmqctl start_app
Starting node rabbit@mysql ...
[mysql ~]# rabbitmqctl cluster_status
Cluster status of node rabbit@mysql ...
[{nodes,[{disc,[rabbit@mysql]}]},
{running_nodes,[rabbit@mysql]},
{cluster_name,<<"rabbit@mysql.domain.com">>},
{partitions,[]}]
Понятия не имею, что пошло не так. В последний раз, когда это произошло, я обновил RabbitMQ qnd Erlang до последней версии.
На основе Документация по кластеру RabbitMQ ваш rabbitmqctl cluster_status вывод выглядит неправильно; running_nodes должен содержать не только локальный узел, на котором вы выполняете команду. Это наводит на мысль, что они не могут нормально разговаривать друг с другом, есть ли между узлами брандмауэры?
У меня возникла эта проблема сегодня при разработке документа о намеренном прерывании для события breakfix, чтобы научить нашу операционную группу, как что-то исправить. Я намеренно исключил узел из кластера и не смог запустить rabbitmqctl join_cluster успешно, потому что кластер полагал, что узел уже является членом.
Узел кластеризации 'rabbit @ node-1' с 'rabbit @ node-0' ... ... done (already_member).
В конечном итоге для меня сработало rabbitmqctl forget_cluster_node rabbit@node-1 от рабочего кластерного узла. Как только я это сделал, я смог успешно запустить rabbtmqctl join_cluster rabbit@node-0
Боджит прав, я могу сказать вам, имея работающий кластер кроликов, что ваша конфигурация неверна. Похоже, что каждый узел - это собственный кластер, и только он сам является текущим работающим узлом.
Вернитесь к документации RabbitMQ по настройке кластера.
На каждом узле вы должны увидеть нечто похожее на следующее:
root@rabbit0:~# rabbitmqctl cluster_status
Cluster status of node 'rabbit@rabbit0' ...
[{nodes,[{disc,['rabbit@rabbit0','rabbit@rabbit1']}]},
{running_nodes,['rabbit@rabbit1','rabbit@rabbit0']},
{cluster_name,<<"rabbit@rabbit0.domain.com">>},
{partitions,[]}]
...done.
root@rabbit1:~# rabbitmqctl cluster_status
Cluster status of node 'rabbit@rabbit1' ...
[{nodes,[{disc,['rabbit@rabbit0','rabbit@rabbit1']}]},
{running_nodes,['rabbit@rabbit0','rabbit@rabbit1']},
{cluster_name,<<"rabbit@rabbit0.domain.com">>},
{partitions,[]}]
...done.
Это дезинфицировано, но приказы и намерения сохранены.
Вам также необходимо настроить высокую доступность, если вы хотите, чтобы ваши очереди работали при отказе: