RabbitMQ - Jak skonfigurować serwery do aktualizacji o zerowym przestoju?

Po przeczytaniu dokumentacji i RabbitMQ w działaniu , tworzenie klastra RabbitMQ wydaje się dość proste, ale aktualizacja lub łatanie istniejącego klastra RabbitMQ wydaje się wymagać ponownego uruchomienia całego klastra.

Czy istnieje sposób na połączenie klastrowania, łopaty, federacji i równoważenia obciążenia, aby umożliwić ciągłą aktualizację bez utraty kolejek lub wiadomości, czy też przeoczyłem coś nieco bardziej oczywistego?

Zakładając, że twoi klienci rabbitmq mogą tolerować zerwane połączenie, możesz rozważyć, co tu opisano .

nasz klaster stoi za VIP-em. Kiedy chcemy zaktualizować klaster, rozpędzamy alternatywny klaster i przełączamy VIP na alternatywny klaster. Tymczasem mamy narzędzia, które przenoszą wiadomości między klastrami. Po zakończeniu aktualizacji klastra „master” cofamy proces.

Podczas aktualizacji z jednej głównej lub mniejszej wersji RabbitMQ do innej (tj. Z 3.0.x na 3.1.x lub z 2.xx na 3.xx), lub podczas aktualizacji Erlang, cały klaster musi zostać zdjęty do aktualizacji ( ponieważ klastry nie mogą uruchamiać takich wersji mieszanych). Nie będzie tak w przypadku aktualizacji z jednej wersji łatki do innej (tj. Z 3.0.x do 3.0.y); wersje te można mieszać w klastrze (z tym wyjątkiem, że 3.0.0 nie można mieszać z późniejszymi wersjami z serii 3.0.x).

@terence Ja też byłem w takich samych butach jak twoje. Myślę, że można ugasić pragnienie ciekawość Cię tu . PS Sam jeszcze tego nie próbowałem.