Прочитав документы и RabbitMQ в действиисоздание кластера RabbitMQ кажется достаточно простым, но обновление или исправление существующего кластера RabbitMQ, похоже, требует перезапуска всего кластера.
Есть ли способ объединить кластеризацию, лопатку, федерацию и балансировку нагрузки, чтобы сделать постепенное обновление возможным без потери очередей или сообщений, или я пропустил что-то более очевидное?
Предполагая, что ваши клиенты rabbitmq могут терпеть разорванное соединение, вы можете рассмотреть то, что описано Вот.
наш кластер находится за VIP. Когда мы хотим обновить кластер, мы запускаем альтернативный кластер и переключаем VIP на альтернативный кластер. Между тем у нас есть инструмент, который перемещает сообщения между кластерами. Когда обновление «главного» кластера завершено, мы обращаем процесс вспять.
При обновлении с одной основной или дополнительной версии RabbitMQ до другой (например, с 3.0.x до 3.1.x или с 2.xx до 3.xx) или при обновлении Erlang весь кластер должен быть отключен для обновления ( поскольку кластеры не могут запускать смешанные версии, как это). Этого не будет при обновлении с одной версии патча до другой (т.е. с 3.0.x до 3.0.y); эти версии могут быть смешаны в кластере (за исключением того, что 3.0.0 нельзя смешивать с более поздними версиями из серии 3.0.x).
@terence Я тоже был в той же обуви, что и ты. Я думаю, ты можешь утолить жажду любопытства Вот. P.S. Сам еще не пробовал.