Ich habe einen MySQL/PHP/Apache-Cluster mit 3 Servern (jeder auf einem anderen Kontinent für maximale Ausfallsicherheit). Ich habe viele Ratschläge gelesen, die alle sagen: Mach das nicht!
Die Gründe, warum ich das tun möchte, sind im Wesentlichen:
- Ausfallsicherheit - 2 von 3 Servern könnten ausfallen und die Benutzer könnten sich trotzdem anmelden und ihre Daten sehen/ihre Arbeit erledigen
- Backup – ungefähr wie oben
- Lastverteilung - Ich kann die Front-End-Last UND die Back-End-Serverprozesse auf die verschiedenen Boxen verteilen
Ich habe mir verschiedene Optionen angesehen, darunter Percona Galera, aber alle scheinen Nachteile zu haben. Der wichtigste ist die Transparenz – irgendwann fällt ein Link oder Server aus, dann bekommt man vage BINLOG-Fehler, und dann ist das Ganze ein riesiges Problem ...
Also habe ich dies stattdessen selbst implementiert - ich habe eine Reihe von Skripten, die INSERT/UPDATE/DELETE-Trigger für jede Tabelle erstellen - alle Änderungen werden in einer Replikationstabelle protokolliert. Ein minütlicher Prozess überträgt diese Änderungen an die anderen beiden Server. Ich habe auch Prozesse, die die PRÜFSUMME überprüfen und bei Unstimmigkeiten warnen.
Es funktioniert großartig. Nicht einfach, das gebe ich zu! Mehrere knifflige Dinge, darunter:
- verwendet keinen Float-Spaltentyp (0,3434 ist nicht gleich 0,3434 …)
- Vermeidung automatisch inkrementeller Schlüssel (wenn Daten gleichzeitig auf zwei verschiedenen Servern eingefügt werden, könnten beide den nächsten Wert annehmen und das gegenseitige Einfügen würde fehlschlagen).
- Denken Sie daran, das Skript zum Erstellen von Triggern erneut auszuführen, wenn Sie eine Tabellenstruktur ändern
Meine Frage ist also: Was könnte schiefgehen? Wo/warum wird das schiefgehen? Was weiß ich nicht??
Antwort1
Im Gegensatz zu dem oben Gesagten halte ich dies für eine ausgezeichnete Frage. Sie verlangen keine Analyse dessen, was sie getan haben, sondern nur das allgemeine „vierte Fenster“ der unbekannten Unbekannten.
Datenintensive Anwendungen sind einausgezeichnetes Buch Sie nennen es Multi-Leader-Replikation statt Master-Master und erläutern ausführlich, warum dies Tücken hat. Wie Sie gesehen haben, tun dies Dienste mit Galera und Percona nicht – es muss also einen guten Grund geben (ich habe noch nicht mit Blackhole gespielt).
Die Kernaussage besteht meiner Meinung nach darin, dass Sie sicherstellen müssen, dass die Tabellenstruktur mit der Replikation mehrerer Leads zurechtkommt. Wenn also zwei neue Einträge auf unterschiedlichen Servern hinzugefügt werden, möchten Sie (wie Sie sagen) kein automatisch inkrementiertes Schlüsselfeld haben. Sie müssen die Tabelle und die Anwendung so konzipiert haben, dass sie möglicherweise die Benutzer-ID und den Zeitstempel usw. verwenden (das ist also eine mühsame Handarbeit).
Sie benötigen wahrscheinlich auch geeignete Tools, um Tabellen verschiedener Datenbanken schnell vergleichen und Inkonsistenzen erkennen zu können.