RabbitMQ: ¿cómo configuro los servidores para las actualizaciones de tiempo de inactividad cero?

Después de leer los documentos y RabbitMQ en acción , crear un clúster RabbitMQ parece bastante sencillo, pero actualizar o parchar un clúster RabbitMQ existente parece requerir que se reinicie todo el clúster.

¿Hay alguna manera de combinar clustering, pala, federación y equilibrio de carga para hacer posible una actualización continua sin perder colas o mensajes, o me he perdido algo un poco más obvio?

Suponiendo que sus clientes rabbitmq puedan tolerar una conexión perdida, puede considerar lo que se describe aquí .

Nuestro clúster está detrás de un VIP. Cuando deseamos actualizar un clúster, activamos un clúster alternativo y cambiamos el VIP al clúster alternativo. Mientras tanto, tenemos herramientas que mueven los mensajes entre grupos. Cuando se realiza la actualización del clúster 'maestro', revertimos el proceso.

Al actualizar de una versión principal o secundaria de RabbitMQ a otra (es decir, de 3.0.x a 3.1.x, o de 2.xx a 3.xx), o al actualizar Erlang, se debe quitar todo el clúster para la actualización ( ya que los clústeres no pueden ejecutar versiones mixtas como esta). Este no será el caso cuando se actualice de una versión de parche a otra (es decir, de 3.0.x a 3.0.y); estas versiones se pueden mezclar en un clúster (con la excepción de que 3.0.0 no se puede mezclar con versiones posteriores de la serie 3.0.x).

@terence Yo también había estado en los mismos zapatos que los tuyos. Creo que puedes calmar tu sed de curiosidad aquí . PD: Todavía no lo he probado.