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