У меня есть 4-узловый кластер Artemis 2.10 в Linux, настроенный для асинхронного журнала ввода-вывода, репликации и размещенных на сервере HA. Я проверял отработку отказа и откат назад, но он не работает. При завершении работы одного сервера (A) в паре HA размещенная совместно резервная копия на втором сервере (B) активирует и корректно обрабатывает сообщения, предназначенные для исходного сервера A. Я изменил пример ColocatedFailoverExample из примеров Artemis, чтобы проверить это, и он работает. Проблема в том, что когда я поднимаю исходный сервер A, он запускается, становится активным, регистрирует акцепторы и адреса и присоединяется к кластеру, но некоторые вещи ошибочны:
, глядя на Артемидуконсоли для сервера A больше нет списка colocated_backup_1, показывающего, что он предоставляет объединенную резервную копию серверу B.
Сервер A, возвращающийся назад, вызывает сервер, к которому был выполнен отказ,сервер B, чтобы полностью отключиться и функционировать только как резервная копия. Мастер, который он предоставлял, останавливается и больше не отображает адреса или получателей в пользовательском интерфейсе.
Хотя он говорит, что он работает в качестве резервного сервера B, он также не имеет объекта colocated_backup_1, показанного в его консоли.
Сервер Bкажется, все еще является частью кластера, но в пользовательском интерфейсе для него больше не показан зеленый главный узел - просто красный круг подчиненного узла. Сбой клиентских подключений к серверу B, скорее всего, из-за того, что на нем был запущен совмещенный мастер.
В пользовательском интерфейсе Artemis для сервера B под именем узла> имя-кластера-подключения> кластер-name атрибуты для кластера не показывают узлов в массиве узлов, а идентификатор узла неверен. Идентификатор узла теперь совпадает с идентификатором главного посредника на сервере A. Это почти так же, как если бы информация для посредника colocated_backup_01 на сервере B, который работал до аварийного переключения, заменила работающий сервер B, и теперь на нем только один посредник. сервер B - совместное резервное копирование.
Все это происходит немедленно, когда я запускаю сервер A. Пользовательский интерфейс для сервера B сразу же обновляется, и запись colocated_backup_01 исчезает, а получатели и адресассылки под именем главного брокера для сервера B просто исчезают. Страница атрибутов кластера обновится, и 3 узла, перечисленные там в атрибуте «узлы», исчезнут, а атрибут «узлы» будет пустым.
Теперь, если я вместо этого отключу сервер В и включу его,роли между парой серверов поменялись местами. Теперь сервер B снова становится активным и отображается как главный узел в топологии (но в пользовательском интерфейсе нет colocated_backup_01), а главный посредник сервера A переходит в автономный режим, а сервер A переконфигурируется как резервный / подчиненный узел. Независимо от того, находится ли сервер A или B в этом «автономном режиме», состояние посредника только для резервного копирования означает, что значение свойства Node в атрибутах кластера, отображаемых в пользовательском интерфейсе, является одинаковым для обоих. Перед выполнением теста отработки отказа у них были разные идентификаторы узлов, что имеет смысл, но резервная копия colocated_backup_01 на каждом из них имела общий идентификатор узла, для которого выполнялось резервное копирование. резервное копирование происходит после отработки отказа, по-видимому, запускает резервный узел своего партнера, чтобы создать резервную копию, но также перестает быть главным узлом. С этого момента парное колокейшн останавливается, и между двумя серверами остается только один живой мастер, а не один на каждом. Похоже, что функция восстановления после отказа не только возвращает исходный мастер, но и выключает совместно расположенный мастер в этой резервной копии. Почти как если бы топология между ними была настроена для совместного размещения, и она рассматривает ее как стандартную конфигурацию HA с двумя узлами, где один сервер является главным, а другой - подчиненным.
Единственный способ исправить проблемус парой, чтобы остановить оба сервера и удалить все в каталоге данных брокера на обоихкоробки, прежде чем начать их снова. Недостаточно просто удалить файлы с резервной копией на каждой машине - все в разделе «данные» должно уйти. После этого они работают правильно, и оба являются живыми мастерами, и они снова объединяются в единую резервную копию для HA.
Вот раздел ha-policy в файле broker.xml, который одинаков для всех4 сервера:
<ha-policy>
<replication>
<colocated>
<backup-request-retries>5</backup-request-retries>
<backup-request-retry-interval>5000</backup-request-retry-interval>
<max-backups>1</max-backups>
<request-backup>true</request-backup>
<backup-port-offset>20</backup-port-offset>
<master>
<check-for-live-server>true</check-for-live-server>
<vote-on-replication-failure>true</vote-on-replication-failure>
</master>
<slave>
<max-saved-replicated-journals-size>-1</max-saved-replicated-journals-size>
<allow-failback>true</allow-failback>
<vote-on-replication-failure>true</vote-on-replication-failure>
<restart-backup>false</restart-backup>
</slave>
</colocated>
</replication>
</ha-policy>