MySQL Dual Master

Question

Für mein aktuelles Projekt denken wir über die Einrichtung einer Dual-Master-Replikationstopologie für ein geografisch getrenntes Setup nach; ein db an der us-ostküste und der andere db in japan. Ich bin neugierig, ob jemand das versucht hat und was dort Erfahrung ist.

Auch ich bin gespannt, was meine anderen Möglichkeiten sind, dieses Problem zu lösen; Wir betrachten Nachrichtenwarteschlangen.

Danke!

Answer 1

Nur eine Anmerkung zu den technischen Aspekten Ihres Plans: Sie müssen wissen, dass MySQL Multi-Master-Replikation (nur MySQL Cluster bietet Unterstützung für synchrone Replikation).

Aber es gibt mindestens einen "Hack", der die Multi-Master-Replikation auch mit einem normalen MySQL-Replikations-Setup ermöglicht. Eine mögliche Lösung finden Sie in Patrick Galbraiths "MySQL Multi-Master Replication". Ich habe keine Erfahrung mit diesem Setup, also wage ich nicht zu beurteilen, wie machbar dieser Ansatz wäre.

Answer 2

Bei der geografischen Replikation von Datenbanken müssen mehrere Punkte berücksichtigt werden. Wenn Sie dies aus Performancegründen tun, stellen Sie sicher, dass Ihr Replikationsmodell Ihre Daten "möglicherweise konsistent" unterstützt, da es einige Zeit dauern kann, bis die Replikation an beiden oder an mehreren Standorten aktuell ist. Wenn Ihr Durchsatz oder die Antwortzeiten zwischen Standorten nicht gut sind, ist die aktive Replikation möglicherweise nicht die beste Option.

Answer 3

Aufgrund der One-to-Many-Architektur der MySQL-Replikation müssen Sie einen Replikationsring mit mehreren Mastern haben. Das heißt, jeder repliziert den nächsten in einer Schleife. Für zwei replizieren sie sich gegenseitig. Dies wurde bereits von v3.23 unterstützt.

In einem früheren Ort arbeitete ich, wir haben es mit v3.23 mit einer ziemlich großen Anzahl von Kunden getan, um genau das zu liefern, was Sie verlangen. Wir verwendeten SSH-Tunnel über das Internet, um die Replikation durchzuführen. Wir brauchten einige Zeit, um es zuverlässig zu machen, und mehrere Male mussten wir eine binäre Kopie einer Datenbank zu einer anderen machen (glücklicherweise war keine von ihnen über 2 GB und brauchte auch keinen 24-Stunden-Zugriff). Auch die Replikation in v3 war nicht annähernd so stabil wie in v4, aber selbst in v5 wird es einfach aufhören, wenn es irgendeine Art von Fehler entdeckt.

Um die unvermeidliche Replikationsverzögerung zu berücksichtigen, haben wir die Anwendung so strukturiert, dass sie nicht auf Felder AUTOINCREMENT angewiesen ist (und dieses Attribut aus den Tabellen entfernt hat). Dies war aufgrund der von uns entwickelten Datenzugriffsebene relativ einfach. Anstatt es für neue Objekte mit mysql_insert_id() zu verwenden, erstellte es zuerst die neue ID und fügte sie zusammen mit dem Rest der Zeile ein. Wir haben auch Site-IDs implementiert, die wir in der oberen Hälfte der ID gespeichert haben, weil sie BIGINT s waren. Das bedeutete auch, dass wir die Anwendung nicht ändern mussten, als wir einen Kunden hatten, der die Datenbank an drei Standorten haben wollte. :-)

Es war nicht 100% robust. InnoDB hat gerade etwas an Sichtbarkeit gewonnen, so dass wir Transaktionen nicht einfach verwenden konnten, obwohl wir es in Betracht gezogen haben. So gab es gelegentlich Rennbedingungen, als zwei Objekte versuchten, mit der gleichen ID erstellt zu werden. Dies bedeutete einen Fehler und wir versuchten dies in der App zu melden. Aber es war immer noch ein wichtiger Teil von jemandes Aufgabe, über die Replikation zu wachen und Dinge zu reparieren, wenn es kaputt ging. Wichtig, um es zu beheben, bevor wir zu weit aus der Synchronisation kamen, weil in einigen Fällen die Datenbanken in beide Sites verwendet wurden und würde schnell schwierig werden, wieder zu integrieren, wenn wir einen neu erstellen mussten.

Es war eine gute Übung, ein Teil davon zu sein, aber ich würde es nicht wieder tun. Nicht in MySQL.

Answer 4

Einrichten von MySQL als Dual-Master funktioniert tatsächlich im richtigen Szenario richtig ausgeführt. Aber ich bin mir nicht sicher, ob es in Ihrem Szenario sehr gut passt.

Zunächst ist Dual-Master-Setup in Mysql wirklich ein Ring-Setup. Server A ist als Master von B definiert, während B gleichzeitig als Master von A definiert ist, so dass beide Server sowohl als Master als auch als Slave fungieren. Die Replikation funktioniert, indem ein binäres Protokoll mit den SQL-Anweisungen geliefert wird, die der Slave einfügt, wenn er es für richtig hält, was normalerweise sofort der Fall ist. Aber wenn Sie es mit lokalen Einfügungen hämmern, wird es eine Weile dauern, um aufzuholen. Die Slave-Einfügungen sind übrigens sequentiell, so dass Sie keinen Vorteil von mehreren Kernen usw. erhalten.

Die primäre Verwendung von Dual-Master-MySQL ist Redundanz auf der Server-Ebene mit automatischer Fail-Over (oft mit hearbeat auf Linux). Ausschließen von mysql-cluster (aus verschiedenen Gründen), dies ist das einzige verwendbare automatische Failover für mysql. Das Setup für den Basis-Dual-Master finden Sie unter google. Das Herzschlagzeug ist ein bisschen mehr Arbeit. Aber das ist nicht wirklich das, wonach Sie gefragt haben, da dies sich wirklich wie ein einzelner Datenbankserver verhält.

Wenn Sie das Dual-Master-Setup wünschen, weil Sie immer in eine lokale Datenbank schreiben möchten (schreiben Sie beide gleichzeitig), müssen Sie Ihre Anwendung mit diesem Gedanken versehen. Sie können in der Datenbank nie automatisch inkrementierende Werte haben. Wenn Sie eindeutige Werte haben, müssen Sie sicherstellen, dass die beiden Speicherorte niemals denselben Wert enthalten. Zum Beispiel könnte Ort A ungerade eindeutige Zahlen schreiben und Ort B könnte sogar eindeutige Zahlen schreiben. Der Grund dafür ist, dass Sie nicht garantieren können, dass die Server zu einem bestimmten Zeitpunkt synchron sind. Wenn Sie also eine eindeutige Zeile in A eingefügt haben und dann eine überlappende eindeutige Zeile in B, bevor der zweite Server aufholt, werden Sie habe ein kaputtes System. Und wenn etwas zuerst bricht, stoppt das gesamte System.

Um es zusammenzufassen: es ist möglich, aber Sie müssen sehr vorsichtig sein, wenn Sie Business-Software auf dem oben genannten bauen.