Wegen Split Brain mache ich mir keine Sorgen, da die Verbindung zwischen den beiden Servern stabil ist (und ich keinen dritten Rechner habe).
Ich möchte eine MariaDB-Replikation mit automatischem Failover haben, damit diese auch dann weiter funktioniert, wenn eine Datenbank ausfällt. Ich habe mir MaxScale angesehen, aber da ich nur zwei Maschinen habe, müsste es auf derselben Maschine wie einer der Server laufen, und wenn dieser Server ausfällt, funktioniert nichts. Soweit ich weiß, verweigern mir MariaDB Galera-Cluster die Ausführung auf nur zwei und ein automatisches Failover (erfordert Quorum). Ich könnte jedoch möglicherweise einen Arbitrator auf einer anderen Maschine oder sogar eine andere Datenbank darauf ausführen, aber das wäre langsam.
Darüber hinaus ist das Backend PHP – ich bin bereit, das MySQL-Setup und dergleichen zu ändern, weiß aber nicht, ob oder was ich dort ändern müsste.
BEARBEITEN: Ich bin bereit, auf automatisches Failover zu verzichten, würde mir dann aber folgendes Verhalten wünschen:
Wenn ich eine Verbindung zu Server A herstelle, stellt dieser eine Verbindung zu Datenbank A (Master) her und liest/schreibt normal.
Wenn ich mich mit Server B verbinde, verbindet er sich mit Datenbank B (schreibgeschützter Slave) und liest problemlos. Wenn er schreiben muss, kann er das, aber er überträgt die Daten in Datenbank A.
Wäre dies mit MaxScale auf beiden Servern oder so etwas möglich?
Antwort1
Sie haben zwei Knoten. Verwenden Sie keine Master-Master-Verbindungen, da die Gefahr eines Split-Brain-Fehlers auf zwei Knoten sehr groß ist (das passiert mit ziemlicher Sicherheit irgendwann).
Von dieser Art zustandsbehafteter Anwendung kann nicht erwartet werden, dass sie die Bereitstellung eines Clusters mit zwei Knoten allein sehr gut handhaben kann. Um den Cluster im Fehlerfall einigermaßen robust zu machen, ist entweder das Eingreifen eines Bedieners oder ein CRM erforderlich. Dies ist der Grund, warum der Cluster überhaupt in einem Cluster erstellt wird.
Sie haben einen Cluster mit zwei Knoten. Sie sollten sich unbedingt über Split-Brain Gedanken machen, da diese Architektur sehr anfällig für Split-Brain-Zustände ist. Nur weil die Netzwerkverbindung zwischen den Knoten heute stabil ist, heißt das nicht, dass dies immer so bleiben wird, und dies ist eine der größten Risikokomponenten in einem Cluster mit zwei Knoten. Der Verlust dieser Verbindung führt sofort zu einem Split-Brain-Cluster, es sei denn,FECHTENoderQUORUMwird zwischen den Knoten eingerichtet. Dies ist eine der wichtigsten Überlegungen in einem Cluster mit zwei Knoten, da durch Fencing die Wahrscheinlichkeit von Split-Brain-Zuständen von hoch auf nahezu Null reduziert wird.
Ich würde empfehlen, dies mit Pacemaker/Corosync zu handhaben. Es ist ein komplizierter Stapel, bietet aber die erforderlichen Mechanismen, um einen produktionstauglichen Cluster mit zwei Knoten zu erstellen. Ich würde auch empfehlen, immer nur eine einzige Masterinstanz gleichzeitig zu verwenden, anstatt mehrere Master, selbst wenn ein solcher Clustermanager dies erzwingt.
Es gibt einen guten Leitfaden für HA MariaDB, der als Ausgangspunkt dienen kann. Er behandelt NICHT die Verwendung von Fencing. Wenn Sie Fencing nicht durchführen können, bietet Corosync auch die Möglichkeit, einen kleinen Arbitrator-Knoten zu verwenden, auf dem ein Abstimmungs-Daemon läuft, um die Gesamtimplementierung ohne Anwendungs-Overhead-Kosten mit Quorum zu versehen (siehe Informationen zu Corosync qdevice).
Es ist hinter einer Abonnement-Wand, aber es ist einEnd-to-End-Anleitung zur Konfiguration eines Active-Passive-MySQL-Clusters, der jeweils auf einem Knoten ausgeführt wird und Blockspeicher zwischen Knoten repliziert
Die erweiterten Ressourcentypen von Pacemaker decken die meisten Ihrer Fragen zur reibungslosen Orchestrierung eines Failovers ab. Sie bieten die Möglichkeit, Ressourcen in lineare Abhängigkeitsketten zu gruppieren und Semantiken für die Leader-Auswahl mit mehreren Zuständen auszudrücken, um mehrere Instanzen einer Anwendung über mehrere Knoten hinweg auszuführen.Das finden Sie hier.
Bundles sind eine Möglichkeit, die Anwendungsisolierung in Pacemaker über Container-Runtimes wie Docker und RKT zu erreichen. Dies eröffnet eine weitere Möglichkeit der Abgrenzung, da diese Bundles dem Cluster selbst als Pacemaker-Knoten erscheinen – sie können also vom Cluster unabhängig von anderen Anwendungen „abgegrenzt“ werden.Das finden Sie hier.
Antwort2
Ich habe verschiedene Datenbanken (Mongo, Elasticsearch, SQL Server, andere) mit der gleichen Philosophie ausgeführt: „Probleme sind mir egal, ich kann nur zwei Knoten ausführen.“
Es war eine WELT voller Schmerz.
Wenn Sie Master-Slave verwenden, ist das in Ordnung. Aber es wird Probleme geben.
Nachdem ich jahrelang um das Problem herumgeredet und mich mit verschiedenen DevOps-Problemen herumgeschlagen hatte, die durch mein Beharren auf nur zwei Knoten verursacht wurden (worauf ich bestand, weil unsere Datenbanken wirklich groß waren und die Kosten für einen dritten Knoten erheblich waren), begann ich schließlich, drei Knoten zu betreiben.
Und dann wurde alles besser.
Die Lektion, die ich aus jahrelangem Tanzen gelernt habe, lautet: Es gibt zwei Möglichkeiten:
- Einzelner Knoten mit warmem ish-Ersatz (z. B. Master-Slave)
- Drei Knoten
Aus meiner Erfahrung würde ich nie wieder zwei Knoten aktiv/aktiv laufen lassen (es sei denn, es gibt eine Zauberformel, die Split Brain vollständig verhindert, was ich gesehen habe und was wahnsinnig hässlich ist).
Aus fünf Jahren Betrieb mehrerer 0,5–1,5 TB großer Datenbanken auf verschiedenen Stacks.
Antwort3
Eine Möglichkeit wäre, eine asynchrone Master-Master-Replikation mit Keepalived auszuführen, um ein Failover über eine Floating-IP durchzuführen. Das ist nicht großartig, würde aber das Szenario eines vollständigen Serverausfalls abdecken.
Haben Sie ILO oder eine andere Möglichkeit, eine Maschine dazu zu bringen, die andere zwangsweise auszuschalten (STONITH)? Dies ist wirklich notwendig, um Teilausfälle zu verhindern, z. B. wenn eine Maschine abstürzt, aber nicht vollständig, sodass sie noch aktiv genug ist, um auf Heartbeat-Pakete zu reagieren, aber ansonsten nicht funktioniert. Dies kann dazu führen, dass das Failover nicht wie vorgesehen erfolgt.