RabbitMQ-cluster nicht wiederherstellen der Verbindung nach Netzwerk-Ausfall
Ich habe RabbitMQ-cluster mit zwei Knoten, die in der Produktion und der cluster bricht mit folgenden Fehlermeldungen:
=ERROR REPORT==== 23-Dec-2011::04:21:34 ===
** Knoten rabbit@rabbitmq02 reagiert nicht **
** Entfernen (timedout) - Anschluss **=INFO REPORT==== 23-Dec-2011::04:21:35 ===
Knoten rabbit@rabbitmq02 verloren 'rabbit'=ERROR REPORT==== 23-Dec-2011::04:21:49 ===
Mnesia(rabbit@rabbitmq01): ** ERROR ** mnesia_event bekam {inconsistent_database, running_partitioned_network, rabbit@rabbitmq02}
Habe ich versucht zu simulieren, das problem durch das töten der Verbindung zwischen zwei Knoten mit "tcpkill", die cluster getrennt wurde,und überraschend die beiden Knoten nicht versucht zu verbinden !
Wenn der cluster bricht, load balancer haproxy noch Noten sowohl Knoten als aktiv und Anfrage senden, um beide von Ihnen, obwohl Sie nicht in einem cluster.
Meine Fragen:
- Wenn die Knoten konfiguriert sind, um als ein cluster, wenn ich einen Netzwerk-Ausfall , warum nicht Sie versuchen, erneut zu verbinden, nachdem ?
- Wie erkenne ich defekte cluster und shutdown einer der Knoten ? Ich habe die Konsistenz Probleme bei der Arbeit mit der zwei-Knoten getrennt.
InformationsquelleAutor Ranch | 2011-12-28
Du musst angemeldet sein, um einen Kommentar abzugeben.
Einen anderen Weg, um erholen sich von dieser Art von Fehler ist das arbeiten mit Mnesia ist die Datenbank, RabbitMQ verwendet die Persistenz-Mechanismus und für die Synchronisation der RabbitMQ-Instanzen (und die master /slave-status) werden von diesem gesteuert. Für alle details schauen Sie bitte die folgende URL: http://www.erlang.org/doc/apps/mnesia/Mnesia_chap7.html
Hinzufügen der relevanten Abschnitt hier:
Dies ist eine langwierige und verwickelte Weise für die Wiederherstellung von solchen Ausfällen .. aber besseren Granularität und Kontrolle über die Daten, die verfügbar sein sollten in der abschließenden master-Knoten (dies kann verringern die Menge von Datenverlust, die auftreten könnten, wenn "Verschmelzung" RabbitMQ-Meister).
InformationsquelleAutor Gur Kamal Singh Badal
RabbitMQ-Cluster nicht gut tun, auf unzuverlässige Netzwerke (Teil von RabbitMQ-Dokumentation). Also, wenn die Netzwerk-Ausfall passiert (in einem cluster mit zwei Knoten) jeder Knoten denkt, dass es der master ist und die nur Knoten im cluster. Zwei master-Knoten nicht automatisch verbinden, weil Ihre Staaten sind nicht automatisch synchronisiert werden (auch im Falle eines RabbitMQ-slave - - die eigentliche Nachricht Synchronisation nicht der Fall ist - der slave nur "Einholt", wie Nachrichten konsumiert, die aus der Warteschlange und mehr Nachrichten Hinzugefügt wird).
Feststellen, ob Sie eine defekte cluster, führen Sie den Befehl:
auf jedem der Knoten, die Teil des Clusters sind. Wenn der cluster defekt ist, dann Sie sehen nur einen Knoten. So etwas wie:
In solchen Fällen müssen Sie zum ausführen der folgenden Befehle auf einem der Knoten, die Teil der ursprünglichen cluster (also, dass er sich mit dem anderen master-Knoten (sagen rabbitmq1) in den cluster als slave):
Schließlich überprüfen Sie die cluster-status wieder .. dieses mal sollte Sie sehen beide Knoten.
Hinweis: Wenn Sie die RabbitMQ-Knoten in einem HA-Konfiguration mit einem Virtuellen IP - (und die clients eine Verbindung zu RabbitMQ über diese virtuelle IP), dann den Knoten, der gemacht werden sollte, der Kapitän sollte derjenige sein, der die Virtuelle IP.
Meines Wissens nach nicht (es sei denn, dies ist in einer neueren version von RabbitMQ ... ich habe nicht geprüft, zumindest für ein Jahr jetzt).
InformationsquelleAutor Gur Kamal Singh Badal
RabbitMQ bietet auch zwei Möglichkeiten für den Umgang mit Netzwerk-Partitionen automatisch: pause-Minderheit-Modus und autoheal-Modus. (Das default-Verhalten wird als bezeichnet ignorieren-Modus).
Im pause-Minderheit-Modus RabbitMQ automatisch pause-cluster-Knoten, die bestimmen, sich in einer Minderheit (d.h. weniger oder gleich als die Hälfte der Gesamtzahl der Knoten) zu sehen, nachdem die anderen Knoten nach unten gehen. Es ist daher wählt partition Toleranz über die Verfügbarkeit von CAP-theorem. Dadurch wird sichergestellt, dass im Falle eines Netzwerk-partition, bei der die meisten Knoten in einer partition laufen weiter.
In autoheal-Modus RabbitMQ automatisch entscheiden, auf einer gewinnen-partition, wenn Sie eine partition ist, gilt als aufgetreten. Es wird starten Sie alle Knoten, die nicht in die Gewinn-partition. Die gewinnen-partition ist die, die die meisten
Automatische Verwaltung der Partitionen angeschlossenen clients (oder, wenn dies produziert eine Attraktion, die man mit den meisten Knoten; und wenn das immer noch produziert zeichnen Sie dann eine der Partitionen gewählt ist, in einer unbestimmten Art und Weise).
Aktivieren Sie entweder Modus aus, indem Sie die Konfigurations-parameter
cluster_partition_handling
für die Hasen-Applikation in Ihre Konfigurationsdatei entwederpause_minority
oderautoheal
., Welchen Modus sollte ich wählen?
Es ist wichtig zu verstehen, dass RabbitMQ auseinandersetzen mit Netzwerk-Partitionen automatisch macht Sie nicht weniger ein problem. Netzwerk-Partitionen wird immer zu Problemen führen, für RabbitMQ-Clustern; Sie nur einige Grad von der Wahl, welche Art von Problemen, die Sie erhalten. Wie bereits in der Einleitung, wenn Sie eine Verbindung herstellen möchten RabbitMQ-Cluster in der Regel über unzuverlässige verbindungen, sollten Sie die
Föderation
plugin oder dieSchaufel
plugin.Mit sagte, dass, möchten Sie vielleicht zu Holen ein recovery-Modus wie folgt:
ignorieren: Ihr Netzwerk ist wirklich zuverlässig. Alle Knoten sind in einem rack, verbunden mit einem Schalter, und der Schalter ist auch der Weg zu der Welt außerhalb. Sie wollen nicht, um eine Gefahr für jede Ihrer cluster Herunterfahren, wenn jede andere versagt er (oder Sie haben einen cluster mit zwei Knoten).
pause_minority: Ihr Netzwerk ist vielleicht weniger zuverlässig. Sie gruppierten sich über 3 AZs, die in EC2, und Sie davon ausgehen, dass nur ein AZ fail auf einmal. In diesem Szenario wollen Sie die restlichen zwei AZs, weiter zu arbeiten, und der Knoten, die der ausgefallenen AZ wieder automatisch und ohne Aufwand, wenn die AZ kommt back.
autoheal: Ihr Netzwerk möglicherweise nicht zuverlässig. Sie sind mehr sorgen um die Kontinuität des Dienstes als mit der Integrität von Daten. Sie haben vielleicht einen zwei-Knoten-cluster.
Diese Antwort ist der ref von rabbitmq docs.
https://www.rabbitmq.com/partitions.html geben Sie eine detaillierte Beschreibung.
InformationsquelleAutor NewPtone