В кластере высокой доступности ActiveMQ Artemis (v2.13.0) политика высокой доступности <scale-down/> заставляет брокер резервного копирования перемещать все ожидающие сообщения в один из оставшихся живых экземпляров, если главный экземпляр выходит из строя. После истощения подчиненный брокер останавливается и ждет, пока главный экземпляр снова не станет активным. Такое поведение эффективно уменьшает количество пар брокеров в кластере, даже если выходит из строя только один главный брокер. Правильно?
Когда <scale-down/> свойство не установлено, подчиненный брокер становится активным при отказе главного сервера, и количество активных брокеров в кластере не изменяется. Однако мне интересно, перемещает ли экземпляр живой резервной копии ожидающие сообщения другим брокерам при намеренном завершении работы (т. Е. SIGTERM). Такое поведение сохранит все сообщения в случае преднамеренного отключения брокера, сохранив при этом количество активных брокеров в случае сбоев.
Такое поведение эффективно уменьшает количество пар брокеров в кластере, даже если выходит из строя только один главный брокер. Правильно?
Это правильно.
Если свойство не установлено, подчиненный брокер становится активным при отказе главного сервера, и количество активных брокеров в кластере не изменяется.
Это тоже правильно.
Однако мне интересно, перемещает ли экземпляр живой резервной копии ожидающие сообщения другим брокерам при намеренном завершении работы (например, SIGTERM).
Если scale-down не настроен, то сообщения перемещаться не будут.
Функциональность уменьшения масштаба действительно была разработана для облачных сценариев использования, где только вживую кластеры будут расти и сокращаться в зависимости от спроса. Когда кластер сжимается, уходящему брокеру нужен способ сохранить свои сообщения, чтобы он сбрасывал их другому брокеру в кластере. Кроме того, инфраструктура облака, как правило, делает конфигурацию HA спорную в связи с управлением и избыточностью, предоставленное само облаком. Например, в случае отказа узла облачная инфраструктура может просто перезапустить его. В этом случае брокер может просто повторно подключиться к тому хранилищу, которое он использовал раньше, и все устойчивые сообщения, которые были там до сбоя (или чего-то еще), все еще будут там.
На мой взгляд, хотя технически возможно использовать горизонтальное масштабирование в конфигурации высокой доступности с живым и резервным копированием, я не думаю, что это имеет особый смысл, поскольку живые и резервные копии уже обмениваются данными сообщений (либо через общие- хранение или репликация).
Наконец, стоит отметить, что уменьшение масштаба можно выполнить административно с помощью ActiveMQServerControl MBean.