Erläuterung des Prinzips des MySQL-Replikationsmechanismus

Hintergrund

Bei der Replikation handelt es sich um eine vollständige Kopie der Daten. Wenn es darum geht, warum wir replizieren müssen, fällt einem als erstes die Angst vor versehentlichem Datenverlust ein, der zu Verlusten für die Benutzer führen kann.

Nach Abschluss der Datenreplikation werden Sie feststellen, dass es noch mehr Vorteile gibt. Wenn eine Maschine ausfällt, können Sie die auf einer anderen Maschine gesicherten Daten aktivieren. Schließlich ist die Wahrscheinlichkeit von Ausfallzeiten sehr gering und die Ersatzmaschine kann in der freien Zeit den Verkehrsdruck der Hauptmaschine teilen. Wenn Sie die Datenbankversion aktualisieren müssen, können Sie darüber hinaus zunächst die Standby-Maschine aktualisieren, ohne die Benutzerdienste zu stoppen, und anschließend die Hauptdatenbank aktualisieren, wenn diese verfügbar und stabil ist.

Allerdings können wir den DBA die Replikation nicht immer durch manuelles Kopieren abschließen lassen. Im Falle eines Absturzes während der Arbeit des DBA werden die während dieser Zeit generierten Daten nicht rechtzeitig gesichert, was zu Datenverlust in der Standby-Datenbank führt. Daher müssen wir noch einen Mechanismus für die automatische Replikation entwickeln.

Entwurf von Replikationsmechanismen

Wir definieren die kopierte Datenbank vorläufig als Master-Datenbank und die eingefügte als Slave-Datenbank. Die Replikation von der Master-Datenbank zur Slave-Datenbank scheint sehr einfach zu sein. Es ist nur eine geplante Aufgabe erforderlich, um regelmäßig eine Kopie der Datendatei der Master-Datenbank zu kopieren und auf den Server zu übertragen, auf dem sich die Slave-Datenbank befindet.

Geplante Aufgaben erfolgen jedoch nicht in Echtzeit. Wenn die Master-Datenbank zehn Minuten nach der letzten Replikation ausfällt, verwendet die aktivierte Slave-Datenbank die zuletzt replizierten Daten. Es fehlen also zehn Minuten an Daten, und die Folgen sind katastrophal.

Wenn weiterhin eine Echtzeitreplikation erforderlich ist, kann die Masterdatenbank jede ausgeführte Anweisung in Echtzeit an die Slavedatenbank senden, sodass die Slavedatenbank sie sofort ausführen kann. Dadurch wird die Datenkonsistenz auf beiden Seiten sichergestellt.

Nicht so gut ist, dass die Master-Datenbank Daten in Echtzeit an die Slave-Datenbank sendet und die nächste Anweisung erst verarbeitet werden kann, nachdem die Slave-Datenbank ihre Ausführung abgeschlossen hat, was die Ausführungszeit der Master-Datenbank erheblich in Anspruch nimmt. Wenn zu viele Slave-Datenbanken vorhanden sind, ist die Master-Datenbank nutzlos.

Um Zeit für die Hauptdatenbank zu sparen, muss es auf asynchron umgestellt werden. Die von der Hauptdatenbank ausgeführten Anweisungen können in einer Datei gespeichert werden und die Slave-Datenbank kann diese abrufen, sodass die Hauptdatenbank nicht auf die Slave-Datenbank warten muss. Da es in eine Datei geschrieben wird, ist die Geschwindigkeit sehr hoch. Die Hauptdatenbank kann die Anweisung vor der Ausführung in die Datei schreiben, um eine höhere Synchronisierungseffizienz zu erreichen.

Bei einigen der oben genannten Probleme kann die Slave-Datenbank nicht zur Master-Datenbank laufen, um Daten abzurufen. Sie kann nur einen Thread starten, um eine Verbindung mit der Master-Datenbank herzustellen und Daten von der Master-Datenbank anzufordern. Dann startet die Master-Datenbank auch einen Thread, um den Dateiinhalt zu lesen und ihn an den Slave-Datenbank-Thread zu senden. Nach Erhalt der Anweisung kann die Slave-Datenbank sie sofort ausführen.

Dies ist immer noch sehr ineffizient. Der Thread der Master-Datenbank muss warten, bis die Slave-Datenbank die Anweisung empfängt und die Ausführung abgeschlossen hat, bevor er die nächste übertragen kann. Wenn mehrere Slave-Datenbanken vorhanden sind, muss die Master-Datenbank mehrere Threads starten, um die langfristige Kommunikation mit jeder Slave-Datenbank aufrechtzuerhalten, wodurch die Serverressourcen der Master-Datenbank belegt werden. Es ist besser, wenn die Slave-Datenbank eine Datei erstellt, um die von der Master-Datenbank gesendete Anweisung vorübergehend zu speichern, diese zuerst zu speichern und dann langsam auszuführen. Dadurch wird der Druck auf die Master-Datenbank verringert und die Slave-Datenbank wird ebenfalls entlastet.

Da der Slave nun über eine eigene Datei für das Relay verfügt, besteht kein Grund zur Sorge. Der Slave kann einen anderen Thread starten und die Anweisungen in der Relay-Datei langsam ausführen. Nach Abschluss der Ausführung hat die Originaldatei keinen Wert und kann bereinigt werden, um die Belegung von Serverressourcen zu vermeiden.

Bisher wurde der grundlegendste Replikationsmechanismus entwickelt. Diese Replikationsmethode von der Master-Datenbank zur Slave-Datenbank ist eine typische Master-Slave-Architektur, die auf dieser Grundlage weiterentwickelt werden kann. Wenn es beispielsweise viele Slave-Datenbanken gibt, muss die Master-Datenbank Daten an jede Slave-Datenbank übertragen, und der Druck auf die Master-Datenbank steigt entsprechend. Da die Verantwortung der Master-Datenbank nicht nur darin besteht, Daten zu synchronisieren, sondern auch Daten zu lesen und zu schreiben, kann die Datensynchronisierungsaufgabe von jemand anderem übernommen werden. Beispielsweise wird eine weitere Master-Datenbank zwischen der Master-Datenbank und der Slave-Datenbank eingerichtet. Die einzige Verantwortung der neu eingerichteten Master-Datenbank besteht darin, Daten mit der Slave-Datenbank zu synchronisieren. Auf diese Weise muss die echte Master-Datenbank nur einmal Daten an die neu eingerichtete Master-Datenbank übertragen und kann sich den Rest der Zeit auf das Lesen und Schreiben von Daten konzentrieren.

Dieser weiterentwickelte Replikationsmodus wird als mehrstufige Replikationsarchitektur bezeichnet. Dieser Artikel endet hier. Die oben genannten sind zwei der drei Replikationsarchitekturen. Darüber hinaus gibt es auch eine „Master-Master“-Architektur. Ich werde hier nicht ins Detail gehen. Wenn Sie interessiert sind, können Sie selbst mehr darüber erfahren oder die nachfolgenden Artikel beachten.

Das Obige ist alles Wissenswerte über den MySQL-Replikationsmechanismus. Vielen Dank für Ihre Unterstützung an 123WORDPRESS.COM.