Frage Architektur für hochverfügbares MySQL mit automatischem Failover an physikalisch unterschiedlichen Standorten


Ich habe High-Availability (HA) -Lösungen für MySQL zwischen Rechenzentren untersucht.

Für Server, die sich in derselben physischen Umgebung befinden, habe ich einen Dual Master mit Heartbeat (Floating VIP) bevorzugt, der einen aktiven passiven Ansatz verwendet. Der Heartbeat ist sowohl über eine serielle Verbindung als auch über eine Ethernet-Verbindung.

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

Es würde BGP an der Spitze sein. Web-Cluster an beiden Standorten, die das Potenzial haben, zu den Datenbanken zwischen beiden Seiten zu routen. Wenn die Internetverbindung an Standort 1 unterbrochen wurde, wurden Clients über Standort 2 an den Webcluster und dann an die Datenbank in Standort 1 weitergeleitet, wenn die Verbindung zwischen beiden Standorten noch besteht.

Bei diesem Szenario besteht aufgrund des Fehlens einer physischen Verbindung (seriell) eine wahrscheinliche Wahrscheinlichkeit für ein geteiltes Gehirn. Wenn das WAN zwischen beiden Standorten ausgefallen wäre, würde der VIP auf beiden Seiten landen, wo eine Vielzahl von unangenehmen Szenarien eine Desynchronisierung verursachen könnte.

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

Die Netzwerkebene ist kein Fokus. Die Architektur ist in diesem Stadium flexibel. Ich konzentriere mich wieder auf eine Lösung zur Aufrechterhaltung der Datenintegrität sowie auf ein automatisches Failover mit den MySQL-Datenbanken. Ich würde wahrscheinlich den Rest entwerfen.

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

Danke, dass Sie sich die Zeit genommen haben, dies zu lesen. Ich freue mich darauf, Ihre Empfehlungen zu lesen.


19
2018-03-01 23:12


Ursprung


Hi - hast du schon einen Ansatz festgelegt? Es wäre interessant zu hören, was Sie beschlossen haben. Wir haben das gleiche Problem. - Martin
Ich schätze all die Antworten und die Zeit jedes Einzelnen. Leider geht keine dieser Antworten wirklich auf die Wurzel der Frage ein, nämlich wie Menschen die Frage in einer Produktionsumgebung erfolgreich gelöst haben. Wenn ich hier zu einer Schlussfolgerung komme, werde ich sicher sein, meine abschließenden Gedanken zu teilen. Bislang scheint dies eine ernsthafte Einschränkung der Skalierbarkeit von MySQL zu sein. - Warner
Vielleicht bekommst du die Schreiblösung nicht, weil du die falsche Frage stellst? Welche Daten müssen Sie replizieren und warum? Wenn Sie anfangen, diese Fragen zu stellen, können Sie herausfinden, warum Sie die Replikation überhaupt erst benötigt haben. Split-Brain ist nicht nur ein MySQL-Problem, es ist ein Cluster-Konzept. - The Unix Janitor
Eine Antwort, die ich hier gegeben habe, enthält einige zusätzliche Informationen: serverfault.com/questions/142683/ ...  Ich werde auch die Nachbearbeitung bereitstellen, wenn die endgültige Produktionsimplementierung vorliegt. - Warner


Antworten:


Sie werden dem Theorem-Problem "CAP" gegenüberstehen. Sie können nicht Konsistenz, Verfügbarkeit und Partitionstoleranz gleichzeitig haben.

DRBD / MySQL HA beruht auf der synchronen Replikation auf Blockgeräteebene. Dies ist in Ordnung, solange beide Knoten verfügbar sind, oder wenn ein vorübergehender Fehler auftritt, neu gestartet wird usw., dann kommt er zurück. Die Probleme beginnen, wenn Sie eine Netzwerkpartition erhalten.

Netzwerkpartitionen sind sehr wahrscheinlich, wenn Sie in zwei Rechenzentren arbeiten. Im Wesentlichen kann keine der Parteien eine Partition vom anderen Knoten unterscheiden. Der sekundäre Knoten weiß nicht, ob er übernehmen soll (der primäre hat gescheitert) oder nicht (der Link ist weg).

Während sich Ihre Maschinen am selben Ort befinden, können Sie einen sekundären Kommunikationskanal hinzufügen (normalerweise ein serielles Kabel oder ein Crossover-Ethernet), um dieses Problem zu umgehen. So weiß der Sekundärcomputer, dass das Primärgerät GENUELL heruntergefahren ist und keine Netzwerkpartition ist .


Das nächste Problem ist die Leistung. Während DRBD eine ordentliche ** Leistung bieten kann, wenn Ihre Maschinen eine Verbindung mit niedriger Latenz haben (z. B. Gigabit-Ethernet - aber manche nutzen dedizierte Hochgeschwindigkeitsnetze), gilt: Je mehr Latenz das Netzwerk hat, desto länger dauert es, eine Transaktion durchzuführen *** . Dies liegt daran, dass es warten muss, bis der sekundäre Server (wenn es online ist) alle Schreibvorgänge bestätigt, bevor "OK" für die App ausgesprochen wird, um die Dauer der Schreibvorgänge sicherzustellen.

Wenn Sie dies in verschiedenen Rechenzentren tun, haben Sie in der Regel mehrere Millisekunden Latenz, selbst wenn sie 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 nicht ordnungsgemäß / automatisch von einem unsauberen Herunterfahren wiederhergestellt wird, das während eines Failovers erforderlich ist.


9
2018-03-03 21:56



Ich schätze deine Zeit und Gedanken. Sie haben einige der Probleme beschrieben, die ich sehr gut vermeiden möchte. Idealerweise möchte ich die Vorteile des aktiven / passiven Dual-Masters für Wartung und schnelles Failover beibehalten und gleichzeitig das Risiko von Datenbeschädigungen minimieren. Ich würde denken, dass jemand da draußen eine akzeptable Lösung gefunden hat. - Warner
Tatsächlich. Daten möchten nicht zwei Orte gleichzeitig sein. - Matt Simmons


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 automatisches Failover verwenden. Verwenden Sie die Datenbankreplikation, um alles synchron zu halten.

Wenn Sie die Rechenzentren besitzen, können Sie sicherstellen, dass jedes Rechenzentrum über mehrere WAN-Uplinks verfügt.


3
2018-03-02 01:37



Das war mein erster Gedanke. Das Einführen der Schicht 2 zu einem solchen Grad würde einen Top-Down-Ansatz zwischen beiden Stellen erfordern. Andere Serverrollen, die mit LinuxHA redundant sind, müssten ähnliche Implementierungen wie die Firewalls haben. Sonst gäbe es Routing-Probleme. Letztlich ist mein Komfortniveau selbst bei mehreren WAN-Uplinks zwischen beiden Standorten wesentlich niedriger als bei seriellen und Ethernet-Uplinks. Das ist mehr Risiko, als ich tolerieren kann. Darüber hinaus scheint es, dass es eine bessere Lösung geben sollte. - Warner


Ihre erste Phase sollte darin bestehen, Ihre aktuelle HA-Lösung auf eine Version zu aktualisieren, die OpenAIS als Cluster-Mitgliedschaftsschicht verwendet. Dies bietet Ihnen viel Flexibilität und kann bei niedrigen Latenzzeiten zwischen den Standorten Verbindungen herstellen. PaceMaker und RHEL Clustering unterstützen dies.

Für das automatische Data Center-Failover benötigen Sie wirklich eine dritte Site, um als Tie-Breaker zu fungieren. Andernfalls können Ihre Standorte nicht zwischen Routingproblemen zwischen Standorten und dem Ausfall von Remote-Standorten unterscheiden. Microsoft hat einige überraschend gute Webcasts, die das Gebiet abdecken:

Windows Server 2008 Multi-Site-Clustering

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


3
2018-03-02 13:37





Entschuldigung das ist noch ein Netzwerk beiseite, aber ein Gedanke für die Straße ...

Für das von Ihnen erwähnte Split-Brain-Szenario könnten Sie auch redundante Verbindungen zwischen zwei Standorten haben, um die Wahrscheinlichkeit dafür zu verringern.


1
2018-03-11 01:50



Ich bin dabei hin und her gegangen. Zuerst habe ich es komplett als zu riskant abgeschrieben. Jetzt überlege ich es mir neu. Realistisch betrachtet ist das Risiko der Datenkorruption sogar mit zwei vollständig diversifizierten Pfaden ziemlich hoch. Es ist gerade auf meiner kurzen Liste. - Warner


Beachten Sie, dass Sie wahrscheinlich BGP nicht verwenden können, da der kleinste routingfähige Block 4k, a / 22 ist, und viel Glück, wenn Sie einen bekommen. Wahrscheinlich wird eine DNS-basierte Lösung benötigt.


0
2018-03-02 01:15



+1 für eine Dosis Realität. Sie können einen gut verwalteten DNS-Dienst wie UltraDNS und seinen Site-Monitoring-Dienst "SiteBacker" verwenden, um den größten Teil des Weges dorthin zu finden. - Martin
Wir haben bereits BGP eingerichtet. Das liegt außerhalb des Rahmens meiner Frage. - Warner
Nein, der kleinste routingfähige Block ist / 24. Eigentlich nicht. Der kleinste physikalisch routingfähige Block ist / 28, aber Sie werden wahrscheinlich von allen ignoriert werden. Das kleinste Präfix, das gehört wird, ist / 24. - Tom O'Connor


Je nachdem, wie viele Daten Sie haben, wie viele Server Sie einsetzen möchten, kann es schwierig sein, eine korrekte Antwort zu geben. Meine Antwort ist vielleicht nicht die eine oder die, nach der Sie suchen.

Es gibt keine bewährte Lösung für mehrere Standorte mit MySQL. Aber es gibt eine Lösung, die funktioniert. Wie einige darauf hinwiesen, funktioniert ja DRDB zwar gut, hat aber je nach Setup ein Limit oder ein mögliches Problem.

Benötigen Sie jemals eine dritte Website (ein anderes Datencenter)? Wenn ja, wie viel Zeit und Geld müssen Sie dafür aufwenden?

Berücksichtigen Sie jedes Mal, wenn Sie einen Master / Slave / DNS-Server, Backups, ... hinzufügen, einen Server zur Verwaltung, was ist Ihre Verwaltungskapazität in Bezug auf die Anzahl der Server? Wenn Sie diese Nummer definieren können, müssen Sie möglicherweise einige mögliche Lösungen wegwerfen und auf diejenigen hinarbeiten, die zu Ihren Zahlen passen, sodass das Management kein Engpass wird.

Wenn man bedenkt, dass Rechenzentren nicht oft herunterfahren, bedeuten mehrere Standorte Load-Balancing und DNS-Hacking, wird sich das im selben Rechenzentrum befinden? Wenn dies der Fall ist, tritt ein Problem auf, wenn ein Rechenzentrum aus irgendeinem Grund ausfällt, da ein guter Teil Ihres DNS und Loadbalancing in diesem Rechenzentrum sein wird.

Also müssen Sie vielleicht diese Split-Brain-Situation planen. Für jede mögliche Einstellung ist der Weg, um eine Spit-Situation zu lösen anders. Außerdem benötigt jede Lösung X Zeit.
Es kann auch viel einfacher sein, 3 Rechenzentren von Anfang an zu verwenden. Ich bin kein MySQL-Experte, aber ich habe gehört, dass es in der Produktion einfacher war, 3 Masters als 2 zu haben, wenn es jemals zu Problemen kam.

Eine Sache, die Ihnen helfen kann, ist Load-Balancing-Service von einem Netzwerk-Anbieter wie Zeus, werfen Sie einen Blick Hier Es gibt wahrscheinlich viele mehr, die diese Art von Service anbieten. Ich bin mir sicher, dass es einen Preis hat, aber manchmal können Sie einige andere Dinge reduzieren.

Viel Glück!


0
2018-03-13 19:55



Die Daten sind relativ klein, alles in allem berücksichtigt. Ein paar hundert Gigabytes um der Diskussion willen. Dritte Seite, wahrscheinlich. Wenn es notwendig ist, bin ich bereit, die Architektur für eine bessere Lösung jetzt zu kompromittieren und später für ein Drittel zu besuchen. "Engpass bei der Verwaltung" oder andere administrative Bedenken liegen außerhalb des Bereichs der Frage. Redundanz ist für alle Produktionstechnologien vorhanden. Der Schwerpunkt liegt hier auf MySQL. - Warner


DRBD ist keine empfohlene Lösung für Remotedatencenter, da eine Bandbreite erforderlich ist, die sich auf die Geschwindigkeit Ihrer Datenbank und Replikation auswirken kann. Die empfohlene Lösung ist Master - Master - Replikation. Das einzige Problem dabei ist, dass Sie Felder automatisch inkrementieren müssen gestaffelt werden.

Wenn Sie eine echte HA-Lösung für MySQL benötigen, müssten Sie MySQL Cluster verwenden, da DRBD Ihnen im Falle von Fehlern keine Datenintegrität geben kann.


0
2017-07-16 17:54