Architektur für hochverfügbares MySQL mit automatischem Failover an verschiedenen Standorten

Ich habe nach Hochverfügbarkeitslösungen (HA) für MySQL zwischen Rechenzentren gesucht.

Für Server, die sich in derselben physischen Umgebung befinden, habe ich Dual Master mit Heartbeat (Floating VIP) unter Verwendung eines aktiven passiven Ansatzes bevorzugt. Der Heartbeat erfolgt sowohl über eine serielle Verbindung als auch über eine Ethernet-Verbindung.

Letztendlich ist es mein Ziel, das gleiche Maß an Verfügbarkeit zwischen Rechenzentren aufrechtzuerhalten. Ich möchte ohne manuelles Eingreifen ein dynamisches Failover zwischen beiden Rechenzentren durchführen und trotzdem die Datenintegrität aufrechterhalten.

Es würde BGP an der Spitze geben. Web-Cluster an beiden Standorten, die möglicherweise zwischen beiden Seiten zu den Datenbanken weitergeleitet werden. Wenn die Internetverbindung an Standort 1 unterbrochen wird, werden Clients über Standort 2 zum Webcluster und dann zur Datenbank an Standort 1 weitergeleitet, wenn die Verbindung zwischen beiden Standorten noch besteht.

In diesem Szenario besteht aufgrund der fehlenden physischen Verbindung (serielle Verbindung) eine größere Wahrscheinlichkeit, dass das Gehirn gespalten wird. Wenn das WAN zwischen beiden Standorten ausfällt, landet der VIP an beiden Standorten, an denen eine Vielzahl von unangenehmen Szenarien zu einer Desynchronisierung führen kann.

Ein weiteres potenzielles Problem ist die Schwierigkeit, diese Infrastruktur in Zukunft auf ein drittes Rechenzentrum zu skalieren.

Die Netzwerkschicht ist kein Fokus. Die Architektur ist zu diesem Zeitpunkt flexibel. Wieder ist mein Fokus eine Lösung für die Aufrechterhaltung der Datenintegrität sowie für das automatische Failover mit den MySQL-Datenbanken. Ich würde den Rest wahrscheinlich darum herum entwerfen.

Können Sie eine bewährte Lösung für MySQL HA zwischen zwei physisch unterschiedlichen Standorten empfehlen?

Vielen Dank, dass Sie sich die Zeit genommen haben, dies zu lesen. Ich freue mich auf Ihre Empfehlungen.

Sie werden mit dem Problem des "CAP" -Theorems konfrontiert sein. Sie können nicht gleichzeitig Konsistenz, Verfügbarkeit und Partitionstoleranz haben.

DRBD / MySQL HA ist auf die synchrone Replikation auf Blockgeräteebene angewiesen. Dies ist in Ordnung, wenn beide Knoten verfügbar sind oder wenn einer einen vorübergehenden Fehler aufweist, neu gestartet wird usw., und dann zurückkommt. Die Probleme beginnen, wenn Sie eine Netzwerkpartition erhalten.

Netzwerkpartitionen sind äußerst wahrscheinlich, wenn Sie auf zwei Rechenzentren ausgeführt werden. Im Wesentlichen kann keine Partei eine Partition von dem anderen ausfallenden Knoten unterscheiden. Der sekundäre Knoten weiß nicht, ob er übernehmen soll (der primäre ist ausgefallen) oder nicht (die Verbindung ist weg).

Während sich Ihre Computer am selben Standort befinden, können Sie einen sekundären Kommunikationskanal (normalerweise ein serielles Kabel oder ein Crossover-Ethernet) hinzufügen, um dieses Problem zu umgehen. Der sekundäre Computer weiß also, wann der primäre Computer WIRKLICH inaktiv ist und es sich nicht um eine Netzwerkpartition handelt .

Das nächste Problem ist die Leistung. Während DRBD eine anständige ** Leistung liefern kann, wenn Ihre Computer über eine Verbindung mit geringer Latenz verfügen (z. B. Gigabit-Ethernet - aber einige Leute verwenden dedizierte Hochgeschwindigkeitsnetzwerke), dauert das Festschreiben einer Transaktion umso länger, je länger die Latenz des Netzwerks ist *** . Dies liegt daran, dass der sekundäre Server warten muss (wenn er online ist), um alle Schreibvorgänge zu bestätigen, bevor er der App "OK" sagt, um die Haltbarkeit der Schreibvorgänge zu gewährleisten.

Wenn Sie dies in verschiedenen Rechenzentren tun, haben Sie in der Regel mehrere Millisekunden Latenz, auch wenn diese in der Nähe sind.

** Immer noch viel langsamer als ein anständiger lokaler IO-Controller

*** Sie können MyISAM nicht für ein DRBD-System mit hoher Verfügbarkeit verwenden, da es nach einem unsauberen Herunterfahren, das während eines Failovers erforderlich ist, nicht ordnungsgemäß / automatisch wiederhergestellt wird.

Wie wäre es mit einem VLAN, um alle Server in den zwei (oder mehr) Rechenzentren miteinander zu verbinden? Sie könnten dann CARP für das automatische Failover verwenden. Verwenden Sie die Datenbankreplikation, um alle Daten synchron zu halten.

Wenn Sie Eigentümer der Rechenzentren sind, können Sie sicherstellen, dass jedes Rechenzentrum über mehrere WAN-Uplinks verfügt.

Der erste Schritt sollte darin bestehen, Ihre aktuelle HA-Lösung auf eine Lösung zu aktualisieren, die OpenAIS als Ebene für die Clustermitgliedschaft verwendet. Dadurch erhalten Sie viel Flexibilität und können möglicherweise Verbindungen mit geringer Latenz zwischen Standorten herstellen. PaceMaker und RHEL Clustering unterstützen dies.

Für ein automatisches Failover von Rechenzentren benötigen Sie wirklich einen dritten Standort, der als Verbindungsunterbrecher fungiert. Andernfalls können Ihre Standorte nicht zwischen standortübergreifenden Routingproblemen und Ausfall eines Remotestandorts unterscheiden. Microsoft hat einige überraschend gute Webcasts für diesen Bereich:

Windows Server 2008-Clustering mit mehreren Standorten

Offensichtlich ist die genaue Technologie nicht auf die Linux-Domäne abgebildet, aber die Konzepte sind dieselben.

Tut mir leid, dies ist ein weiteres Netzwerk, aber ein Gedanke für die Zukunft ...

In dem von Ihnen erwähnten Split-Brain-Szenario könnten Sie auch redundante Verbindungen zwischen zwei Standorten haben, um die Wahrscheinlichkeit zu verringern, dass dies geschieht.

Beachten Sie, dass Sie BGP wahrscheinlich nicht verwenden können, da der kleinste routbare Block 4k, a / 22 ist. Möglicherweise wird eine DNS-basierte Lösung benötigt.

Es kann schwierig sein, eine richtige Antwort zu geben, abhängig von der Datenmenge, der Anzahl der Server, auf die Sie diese Informationen übertragen möchten usw. Abgesehen davon ist meine Antwort möglicherweise nicht die richtige oder zumindest die gesuchte.

Es gibt keine bewährte Lösung für mehrere Sites mit MySQL. Aber es gibt eine Lösung, die funktioniert. Wie einige wiesen darauf hin, funktioniert DRDB zwar einwandfrei, hat aber je nach Konfiguration seine Grenzen oder mögliche Probleme.

Benötigen Sie jemals einen dritten Standort (ein anderes Rechenzentrum)? Wenn ja, wie viel Zeit und Geld müssen Sie dafür aufwenden?

Wenn Sie jedes Mal, wenn Sie einen Master- / Slave- / DNS-Server, Backups usw. hinzufügen, einen zu verwaltenden Server hinzufügen, wie hoch ist Ihre Verwaltungskapazität in Bezug auf die Anzahl der Server? Wenn Sie diese Zahl definieren können, müssen Sie möglicherweise einige mögliche Lösungen verwerfen und auf die hinarbeiten, die zu Ihren Zahlen passen, damit das Management nicht zu einem Engpass wird.

Angesichts der Tatsache, dass Rechenzentren nicht oft ausfallen, bedeutet mehrere Standorte einen Lastenausgleich und DNS-Hacking. Befindet sich dies im selben Rechenzentrum? Wenn ja, wenn ein Datencenter aus irgendeinem Grund ausfällt, treten Probleme auf, da ein Großteil Ihres DNS und des Lastenausgleichs in diesem Datencenter stattfinden wird.

Möglicherweise müssen Sie also die Situation mit dem gespaltenen Gehirn planen. Für fast jede mögliche Konfiguration ist die Art und Weise, wie eine Spuckgehirnsituation gelöst wird, unterschiedlich. Außerdem benötigt jede Lösung X Zeit.
Es kann auch wesentlich einfacher sein, die Verwendung von 3 Rechenzentren von Anfang an zu planen. Ich bin kein MySQL-Experte, aber ich habe gehört, dass es in der Produktion einfacher war, 3 Master als 2 zu haben, wenn Sie jemals auf ein Problem stießen.

Eine Sache , die Ihnen Last helfen kann , ist Balancing Service durch einen Netzwerkanbieter wie Zeus angeboten, einen Blick hier gibt es wahrscheinlich noch viel mehr bietet diese Art von Service. Ich bin sicher, es hat einen Preis, aber manchmal können Sie einige andere Dinge einschränken.

Viel Glück!

DRBD ist keine empfohlene Lösung für Remote-Rechenzentren, da dafür Bandbreite erforderlich ist, die die Geschwindigkeit Ihrer Datenbank und Replikation beeinträchtigen kann. Die empfohlene Lösung ist Master-Master-Replikation. Das einzige Problem dabei ist, dass Sie automatisch inkrementierte Felder versetzen müssen.

Wenn Sie eine echte HA-Lösung für MySQL benötigen, müssen Sie sich für MySQL Cluster entscheiden, da DRBD Ihnen bei Fehlern keine Datenintegrität bieten kann.

Ich habe Blogposts über die in MySQL verfügbaren Optionen und deren Vor- und Nachteile gefunden. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Das Fehlen eines seriellen Kabels zu überwinden ist eigentlich ganz einfach. Sie verwenden ein Gerät aus der dunklen Zeit, das als Modem bezeichnet wird. Sie haben an jedem Ende eines und führen Heartbeat über die PPP-Verbindung aus. Sie können auch Frame Relay verwenden. Beide Methoden beheben alle Probleme, die Sie mit redundanten Pfaden der Ebene 1/2 haben.

Allerdings wird DRBD, das über eine Verbindung mit einer Latenz von mehr als 300 µs (beachten Sie, dass dies 0,3 ms sind) läuft, sehr schnell lächerlich.

Sie sollten die standardmäßige MySQL-Replikation und LinuxHA über PPP & eth verwenden, um die Failovers durchzuführen.

Zumindest habe ich das in der Vergangenheit für Kunden getan.