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