MySQL dual-master-Replikation — ist dieses Szenario sicher?
Ich habe derzeit eine MySQL-dual-master-Replikation (A<->B) eingerichtet, und alles scheint zu laufen geschmiert. Ich zog auf die grundlegenden Ideen von hier und hier.
Server A ist mein web-server (VPS). Benutzerinteraktion mit der Anwendung führt zu updates, um mehrere Felder in der Tabelle X (replizierten server B). - Server B ist der " heavy-lifter, wo all die großen Berechnungen fertig sind. Ein cron-job auf server B regelmäßig fügt Zeilen in Tabelle X (die werden repliziert auf server A).
Also server A aktualisiert werden kann (aber nie zu ergänzen) Zeilen, und server B können Zeilen hinzufügen. Server B kann auch die update-Felder in X, aber nur nach der Benutzer hat nicht mehr die Fähigkeit zu aktualisieren, dass die Zeile.
Welche Arten von möglichen Katastrophen kann ich erwarten, dass Sie dieses Szenario, wenn ich in die Produktion gehen mit ihm? Oder scheint dies OK? Ich Frage hauptsächlich, weil ich bin unwissend darüber, ob alle gleichzeitigen Betrieb auf dem Tisch (entweder in der Kopie oder die B-Kopie) kann Probleme verursachen, oder wenn es sich nur um Vorgänge auf der gleichen Zeile bekommen, dass haarige.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Dual-master-Replikation ist chaotisch, wenn Sie zu schreiben versuchen, um die gleiche Datenbank auf beiden Meister.
Einer der größten Streitpunkte (und hohem Blutdruck) ist die die Verwendung von autoincrement-keys.
Solange Sie daran denken, auto_increment_increment und auto_increment_offset, können Sie die lookup-Daten, die Sie möchten, abrufen und auto_incremented ids.
Du musst nur daran erinnern, von dieser Regel: Wenn Sie Lesen, eine id von serverX, müssen Sie lookup benötigt Daten von serverX mit der gleichen id.
Hier ist eine rettende Gnade für die Verwendung von dual-master-Replikation.
Angenommen, Sie haben
Wenn Sie schreiben die folgenden Einschränkungen
dann sind Sie nicht erforderlich ist, um auto_increment_increment und auto_increment_offset.
Ich hoffe meine Antwort klärt das gute, das schlechte und das hässliche der Verwendung von dual-master-Replikation.
Denke ich, dass Sie sich verlassen können
Percona XtraDB Cluster Feature 2: Multi-Master replication
als normale MySQL-ReplikationDurch Multi-Master meine ich die Fähigkeit zu schreiben auf alle Knoten im cluster und Mach dir keine sorgen, schließlich bekommen Sie out-of-sync-situation, da es regelmäßig geschieht mit regulären MySQL-Replikation aus, wenn du unvorsichtig schreiben auf dem falschen server.
Mit Cluster schreiben Sie zu jedem Knoten und der Cluster gewährleistet die Konsistenz der schreibt. Das ist das schreiben wird entweder ein commit auf allen Knoten oder nicht verpflichtet sich an alle.
Ersten: wir können mehrere appliers parallel arbeiten. Dies gibt uns die wahre parallele Replikation. Slave kann viele parallelen threads, und Sie können es einstellen, indem Sie die variable wsrep_slave_threads
Zweite: möglicherweise gibt Es eine kleine Zeit, wenn die slave-out-of-sync vom master. Dies geschieht, weil die master-Ereignis gelten können, schneller als ein Sklave. Und wenn Sie von slave liest, können Sie Daten Lesen, die nicht verpasst noch. Sie können sehen, dass aus dem Diagramm. Allerdings können Sie dieses Verhalten ändern, indem mithilfe von Variablen wsrep_causal_reads=AUF. In diesem Fall ist das Lesen auf der slave wartet, bis Ereignis angewendet wird (dies wird jedoch mit Zunahme der Reaktionszeiten der Lesen. Diese Lücke zwischen slave und master ist der Grund, warum diese Replikation mit dem Namen "
virtually synchronous replication
" nicht real "synchronous replication
"Dem beschriebenen Verhalten der COMMIT-hat auch der zweite ernsthafte Auswirkungen.
Wenn Sie ausführen, schreiben Transaktionen, die zu zwei verschiedenen Knoten, cluster verwendet werden, eine optimistische locking-Modell.
Das bedeutet, dass eine Transaktion nicht prüfen Sie auf mögliche sperrkonflikte bei einzelnen Abfragen, sondern auf die COMMIT-Phase. Und Sie erhalten möglicherweise die FEHLERMELDUNG als Antwort auf COMMIT. Ich bin auf dieses, da dies eine Inkompatibilität mit regelmäßigen InnoDB, die auftreten können. InnoDB in der Regel DEADLOCK und LOCK TIMEOUT-Fehler auftreten, die in Reaktion auf bestimmte Abfrage, aber nicht auf VERPFLICHTEN. Gut, wenn Sie eine gute Praxis, die du noch check-Fehler-code nach dem "COMMIT" - Abfrage, aber ich sah viele Anwendungen, die dies nicht tun.
Sie finden es hier entlang mit malerischen expln
Master-Master-Replikation kann sehr schwierig sein, sind Sie sicher, dass dies die beste Lösung für Sie ? Normalerweise wird es benutzt, für das load-balancing Zwecke (z.B. round-robin-Verbindung zu deinem db-Server) und manchmal, wenn Sie wollen vermeiden, dass die Replikation Verzögerung Wirkung. Ein großes bekanntes Problem ist die auto_increment-problem, das angeblich gelöst mit verschiedenen offsets und Inkrement-Wert.
Ich denke, Sie sollten ändern Sie die Konfiguration auf einfache master-slave durch Einen master und B der slave, wenn ich nicht Irre, über die Anforderungen Ihres Systems.
Aus meiner ziemlich umfangreichen Erfahrung zu diesem Thema kann ich sagen Sie werden es bereuen, zu schreiben, um mehr als einen master eines Tages. Es kann bald sein, kann es nicht für eine lange Zeit, aber es wird passieren. Sie haben zwei Server mit je einigen korrekten Daten und falschen Daten, und Sie wird entweder wählen Sie eine als die maßgebliche Quelle und werfen Sie die anderen Weg (vermutlich ohne wirklich zu wissen, was Sie wegwerfen) oder Sie versöhnen sich die beiden. Egal wie Sie es planen, können Sie beseitigen die Möglichkeit, dass dies geschieht, so ist es eine mathematische Gewissheit, dass es passieren wird irgendwann.
Percona (mein Arbeitgeber) behandelt hat vermutlich mehrere hundert Fällen der Erholung nach tun, was Sie versuchen. Einige Stunden, einige Wochen in Anspruch nehmen, eines, das ich mit geholfen habe ein paar Monate ab-und das mit ausgezeichneten Werkzeugen, um zu helfen.
Verwenden Sie eine andere Technologie Replikation oder einen anderen Weg finden, das zu tun, was Sie tun möchten. MMM wird nicht helfen-es bringt die Katastrophe früher. Sie können dies nicht mit standard-MySQL-Replikation, mit oder ohne externe tools. Sie brauchen einen Ersatz Replikations-Technologie wie Continuent Tungsten oder Percona XtraDB Cluster.
Ist es oft einfacher einfach zu lösen, den tatsächlichen Bedarf in irgendeiner anderen Weise und geben bis zu multi-master schreibt, wenn Sie verwenden möchten, Vanille MySQL-Replikation.
und vielen Dank für das teilen meiner Master-Master Mysql cluster-Artikel. Als Rolando geklärt diese Konfiguration ist nicht geeignet für die meisten Produktions-Umgebung durch die Beschränkung der autoincrement-Unterstützung.
Die am besten geeignete Weg, um einen MySQL-cluster ist mit NDB, die benötigen mindestens 4 Server (2-management-und 2-Daten-Knoten).
Ich geschrieben habe, einen ausführlichen Artikel zu bekommen, dieser läuft auf zwei Servern nur, die ist sehr ähnlich zu meinem vorherigen Artikel, aber mit NDB statt.
http://www.hbyconsultancy.com/blog/mysql-cluster-ndb-up-and-running-7-4-and-6-3-on-ubuntu-server-trusty-14-04.html
Feststellen, dass ich immer empfehlen, analysieren Ihre Anforderungen und finden Sie heraus, die am besten geeignete Lösung, schauen Sie nicht nur nach verfügbaren Lösungen und versuchen Sie herauszufinden, ob Sie passen mit Ihren Anforderungen oder nicht.
-Hatem
Ich würde empfehlen, auf der Suche in ein tool, verwalten diese für Sie. Multi-master-Replikation kann sehr lästig sein, wenn die Dinge schief gehen.
Ich würde vorschlagen, etwas wie Percona XtraDB Cluster. Ich verfolge dieses Projekt, und es sieht sehr cool. Ich denke auf jeden Fall wird es ein Spiel-wechsler in der MySQL-Welt. Es ist noch in der beta aber.