RabbitMQ - неожиданные пустые и несинхронизируемые очереди после кластерного отказа узла
Я не думаю, что они представляют потоки Java, так как у каждого из них есть различный PID.
У Вас мог бы быть padmin пользователь (или пользователь root, или тот, кто может использовать sudo с этой целью, и т.д.) проверяют командные строки этих соответствующих процессов Java, с помощью любого из этих методов (заменяющий pid соответствующим числом от главного вывода - 27132, 7169, и т.д.):
PS-ef | grep pid
или
кошка/proc/pid/cmdline
Таким образом, по крайней мере, можно начать выяснять, где от каждого из них назвали, и что он делает.
Та же проблема, но нужно кое-что понять, а также возможную ловушку.
Во-первых, меня обманул тот факт, что я не передал свой виртуальный хост команде :
rabbitmqctl set_policy -p myvhost HA '*' '{"ha-mode": "all"}'
В противном случае vhost по умолчанию равен "/"
После этого, когда я вошел в веб-консоль, я увидел, что поле узла сообщает о двух узлах ... сейчас. Отлично: -)
Однако, если вы поднимите и опустите один, затем другой вверх и вниз, очередь исчезнет !? Это потому, что в зеркальном отображении НЕТ «синхронизации», ТОЛЬКО «стек». Это означает, что если вы отключите узел, остальные сообщения будут отправляться от оставшегося узла (или узлов). Если вы запускаете новый / существующий узел, он будет отражать только добавленные НОВЫЕ сообщения.
I ' m довольно новичок в этом, поэтому я предполагаю, что иметь 3 узла было бы намного лучше, чем два. Это означает, что если один узел выходит из строя, устойчивость по-прежнему сохраняется по сравнению с двумя другими узлами (в зависимости от вашего бизнес-случая). Конечно, если два узла выходят из строя, вы теряете репликацию для всего, что осталось в очередях. Я считаю, что это следует называть «сетап с тремя ударами»!