Поврежденный перезапуск 'привычки кластера RabbitMQ
Я выполняю 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 до последней версии.
Сегодня у меня возникла эта проблема, когда я проектировал документ о преднамеренном прерывании для события breakfix, чтобы научить нашу операционную группу, как что-то исправить. Я намеренно исключил узел из кластера и не смог успешно запустить rabbitmqctl join_cluster , потому что кластер полагал, что узел уже является членом.
Узел кластеризации 'rabbit @ node-1' с 'rabbit @ node- 0 '... ... выполнено (уже_ член).
В конечном итоге у меня сработало rabbitmqctl Forgot_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.
Это очищено, но порядок и намерение сохранены.
Вам также необходимо настроить высокую доступность, если вы хотите, чтобы ваши очереди работали после отказа:
На основании документации кластера RabbitMQ ваш вывод rabbitmqctl cluster_status выглядит неверно; running_nodes должен содержать не только локальный узел, на котором вы выполняете команду. Это наводит на мысль, что они не могут нормально разговаривать друг с другом, есть ли между узлами брандмауэры?