RabbitMQ - Come configuro i server per aggiornamenti a zero downtime?

Dopo aver letto i documenti e RabbitMQ in azione , la creazione di un cluster RabbitMQ sembra abbastanza semplice, ma l'aggiornamento o la correzione di un cluster RabbitMQ esistente sembra richiedere il riavvio dell'intero cluster.

Esiste un modo per combinare clustering, pala, federazione e bilanciamento del carico per rendere possibile un aggiornamento continuativo senza perdere code o messaggi o ho perso qualcosa di leggermente più ovvio?

Supponendo che i tuoi client rabbitmq possano tollerare una connessione interrotta, puoi considerare ciò che è descritto qui .

il nostro cluster è dietro un VIP. Quando vogliamo aggiornare un cluster, creiamo un cluster alternativo e passiamo dal VIP al cluster alternativo. Nel frattempo, disponiamo di strumenti che spostano i messaggi tra i cluster. Al termine dell'aggiornamento del cluster "master", il processo viene invertito.

Quando si esegue l'aggiornamento da una versione principale o secondaria di RabbitMQ a un'altra (ovvero da 3.0.xa 3.1.x, o da 2.xx a 3.xx) o durante l'aggiornamento di Erlang, è necessario rimuovere l'intero cluster per l'aggiornamento ( poiché i cluster non possono eseguire versioni miste come questa). Questo non sarà il caso dell'aggiornamento da una versione di patch a un'altra (ovvero da 3.0.xa 3.0.y); queste versioni possono essere mescolate in un cluster (ad eccezione del fatto che 3.0.0 non può essere miscelato con versioni successive della serie 3.0.x).

@terence Anch'io ero stato nelle stesse scarpe del tuo. Penso che si possa placare hai sete di curiosità qui . PS Non l'ho ancora provato da solo.