Когда экземпляр брокера запускается впервые, он инициализирует свой журнал. Одна из вещей, которые брокер делает на этом этапе инициализации, - это генерировать UUID, который будет использоваться для уникальной идентификации брокера для таких вещей, как кластеризация. Это называется «идентификатором узла».
Обычно, когда пользователи видят There are more than one servers on the network broadcasting the same node id, это означает, что они вручную скопировали журнал одного брокера другому брокеру. Обычно это делается, когда пользователи изначально настраивают кластер брокеров, потому что они хотят скопировать конфигурацию вместо того, чтобы начинать с нуля на каждом узле. Однако вместо того, чтобы просто копировать broker.xml на другой узел, также копируется весь журнал, а поскольку журнал содержит уникальный «идентификатор узла», оба брокера в конечном итоге используют один и тот же идентификатор.
Решение в этой ситуации - удалить журнал (по умолчанию хранящийся в каталоге data) у одного из брокеров, регистрирующих это сообщение. Журнал будет повторно инициализирован, и после перезапуска брокера будет создан новый идентификатор узла.
Это сообщение WARN также может быть записано в журнал, если у вас настроен HA, и ведущий и ведомый активны. в то же время. Главный и подчиненный, естественно, имеют один и тот же идентификатор узла, потому что у них один и тот же журнал (через общее хранилище или репликацию). Однако только один брокеров должен быть активным. Если оба брокера активны, это называется «сплит-мозг». Эта ситуация может быть очень проблемной c, потому что оба брокера будут работать независимо с одними и теми же данными журнала. Это может привести к дублированию сообщений, а также к кажущейся потере сообщений, и может быть чрезвычайно сложно (если не невозможно) восстановить целостность данных.
В конфигурации с общим хранилищем само общее хранилище снижает риск раздвоения мозга из-за общих блокировок файлов в журнале. Только одному брокеру физически разрешен доступ к данным журнала. копия данных. Если сетевое соединение между ведущим и ведомым выходит из строя, ведомое устройство не имеет реального способа узнать наверняка, действительно ли ведущее устройство умерло или это была просто проблема сети. Вот почему в документации рекомендуется использовать как минимум 3 пары live / backup . Это позволяет создать надлежащий кворум, чтобы активные члены кластера могли проголосовать за определение правильного переключения при отказе. простой случай, когда произошло аварийное переключение, и вы перезапускаете главный брокер без предварительного выключения подчиненного. Без <check-for-live-server>true</check-for-live-server> главный брокер просто запустится, не проверяя, транслирует ли другой брокер (например, его резервная копия) свой идентификатор узла.