Prinzip und Anwendung der MySQL-Master-Slave-Synchronisation

1. Master-Slave-Synchronisationsprinzip

Diagramm der Master-Slave-Synchronisationsarchitektur (asynchrone Synchronisation)

Dies ist die am häufigsten verwendete Master-Slave-Synchronisierungsarchitektur.

Master-Slave-Synchronisationsprozess (asynchrone Synchronisation)

• Die Hauptdatenbank schreibt Datenänderungen in die binlog Datei
• Initiieren Sie eine dump -Anforderung vom I/O-Thread der Bibliothek
• Der Master-E/A-Thread überträgt binlog an den Slave.
• Schreiben Sie die lokale relay log aus dem I/O-Thread der Bibliothek (dasselbe Format wie binlog )
• Der Slave-SQL-Thread liest relay log und führt es seriell erneut aus, um dieselben Daten wie die Master-Datenbank zu erhalten.

Was ist Binlog?

Jedes Mal, wenn die Hauptdatenbank eine Transaktion ausführt, zeichnet sie die Datenänderungen in einer Binärdatei namens binlog auf. Hinweis: Im binlog werden nur Schreibvorgänge aufgezeichnet, schreibgeschützte Vorgänge (wie etwa select und show Anweisungen) nicht.

Drei Binlog-Formate

Anweisungsformat: binlog zeichnet die tatsächlich ausgeführten SQL-Anweisungen auf
Zeilenformat: binlog zeichnet die Daten vor und nach der Änderung auf (unter Einbeziehung aller Spalten), z. B. update table_a set col1=value1 , col2=value2 ... where col1=condition1 and col2=condition2 ...
Gemischtes Format: Das statement ist standardmäßig ausgewählt und das row wird nur bei Bedarf verwendet.

Vergleich der Binlog-Formate

• Anweisungsebene: Der Vorteil besteht darin, dass die binlog Datei klein ist. Der Nachteil besteht jedoch darin, dass das langsame SQL der Master-Datenbank auch in der Slave-Datenbank erneut angezeigt wird und einige Funktionen, die von der Umgebung oder dem Kontext abhängen, zu inkonsistenten Daten führen können.
• Zeilenebene: Der Nachteil besteht darin, dass die Datei groß ist (wenn eine Anweisung mehrere Zeilen umfasst, wird sie n-mal vergrößert). Der Vorteil besteht darin, dass das oben erwähnte langsame SQL-Problem nicht auftritt und es nicht von der Umgebung oder dem Kontext abhängt.
• Um die Daten vor und nach der Änderung zu erhalten, empfiehlt canal die Verwendung row Zeilenebene

Zwei Möglichkeiten der Master-Slave-Synchronisation

• Asynchrone Synchronisierung: Im Standardmodus kann es beim Master-Slave-Umschalten zu Datenverlust kommen. Denn ob die Master-Datenbank commit ist, hat nichts mit dem Master-Slave-Synchronisationsprozess zu tun und wird nicht wahrgenommen.
• Halbsynchron: Eine Hochverfügbarkeitslösung, die von neueren mysql Versionen unterstützt wird. Sie erfordert mindestens einen Slave (der Standardwert ist 1, die genaue Anzahl kann angegeben werden), der das Schreiben in relay log bestätigt, bevor der Master das Ergebnis commit und an client zurückgibt.

Master-Slave-Synchronisationsprozess (halbsynchron)

• Beim Verbinden mit dem Master zeigt der Slave an, dass er die semisynchrone Replikation unterstützt.
• Die Master-Datenbank muss außerdem halbsynchrone Replikation unterstützen. Vor commit einer Transaktion blockiert die Master-Datenbank und wartet, bis mindestens eine Slave-Datenbank ack in relay log schreibt, bis das Timeout eintritt.
• Wenn die Wartezeit für die Blockierung abgelaufen ist, wechselt die Masterdatenbank vorübergehend zurück in den asynchronen Synchronisierungsmodus. Wenn die Halbsynchronisierung mindestens einer Slavedatenbank den Fortschritt eingeholt hat, wechselt die Masterdatenbank zurück in den Halbsynchronisierungsmodus.

Teilsynchrone Anwendungsszenarien

Hochverfügbare Sicherung: Die halbsynchrone Replikation stellt die Konsistenz zwischen der Slave- und der Master-Datenbank sicher. Wenn die Master-Datenbank ausfällt, führt das Umschalten auf die Slave-Datenbank nicht zu Datenverlust. Um die Stabilität zu gewährleisten (um die Hauptdatenbank nicht durch eine langsame Teilsynchronisierung zu beeinträchtigen), wird es im Allgemeinen nicht von Geschäftsverkehr belastet, ack so schnell wie möglich und wird nur zur Synchronisierung und Sicherung verwendet.

2. Anwendungsszenario für die Master-Slave-Synchronisation

Häufige Szenarien : Asynchrone Synchronisierung von Online-Slaves und Semi-Synchronisierung von hochverfügbaren Backups

Großer Datenerfassungsbedarf mit hohen Konsistenzanforderungen

Das Abrufen großer Datenmengen kann dazu führen, dass die CPU-Auslastung der Slave-Datenbank in die Höhe schnellt und die Bestätigungen langsamer werden. Die Anzahl der für die Halbsynchronisierung erforderlichen Bestätigungen kann auf 1 gesetzt werden. Unter normalen Umständen kann die hochverfügbare Sicherung schnell ack , sodass die Master-Datenbank commit und zurückkehrt. Es spielt keine Rolle, ob das Abrufen großer Datenmengen und die Replikation langsamer sind. Auf diese Weise werden die Hauptdatenbank und das Geschäft nicht durch die langsame ack beim Abrufen großer Datenmengen beeinträchtigt.

Dies ist das Ende dieses Artikels über das Master-Slave-Synchronisationsprinzip und die Anwendung von MySQL. Weitere relevante Inhalte zum Master-Slave-Synchronisationsprinzip und zur Anwendung von MySQL finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!