Eine einfache Erklärung der parallelen MySQL-Replikation

1. Hintergrund der parallelen Replikation

Zunächst einmal: Warum gibt es dieses Konzept der parallelen Replikation?

1. DBAs sollten wissen, dass die MySQL-Replikation auf Binlog basiert.

2. Die MySQL-Replikation besteht aus zwei Teilen, dem IO-Thread und dem SQL-Thread.

3. Der IO-Thread wird hauptsächlich verwendet, um das vom empfangenden Master übergebene Binlog abzurufen und in das Relay-Protokoll zu schreiben

4. Der SQL-Thread ist hauptsächlich für das Parsen des Relay-Protokolls und dessen Anwendung auf den Slave verantwortlich

5. In jedem Fall sind die IO- und SQL-Threads Single-Threaded, während der Master Multi-Threaded ist, sodass es zwangsläufig zu Verzögerungen kommt. Um dieses Problem zu lösen, wurde Multi-Threading eingeführt.

6. IO-Multithreading?

6.1 Es besteht kein Bedarf für Multithreading von IO, da IO-Threads nicht den Engpass darstellen.

7. SQL-Multithreading?

7.1 Ja, die neuesten Versionen 5.6, 5.7 und 8.0 implementieren alle Multithreading im SQL-Thread, um die Parallelität des Slaves zu verbessern.

Als Nächstes werfen wir einen Blick auf die Bemühungen und Erfolge von MySQL bei der parallelen Replikation.

II. Wichtige Punkte

Ob dies parallel erfolgen kann, hängt davon ab, ob es Sperrkonflikte zwischen mehreren Transaktionen gibt. Dies ist der Schlüssel. Das folgende Prinzip der parallelen Replikation zeigt, wie Sperrkonflikte vermieden werden können.

Schemabasierte parallele Replikation in MySQL 5.6

slave-parallel-type=DATABASE (Transaktionen in verschiedenen Datenbanken, keine Sperrkonflikte)

Wie bereits erwähnt, besteht der Zweck der parallelen Replikation darin, den Slave so multithreaded wie möglich laufen zu lassen. Natürlich ist Multithreading auf Bibliotheksebene auch eine Möglichkeit (Transaktionen in verschiedenen Bibliotheken, keine Sperrkonflikte).

Lassen Sie uns zunächst über die Vorteile sprechen: Es ist relativ einfach zu implementieren und für Benutzer leicht zu verwenden. Lassen Sie uns dann über die Nachteile sprechen: Da es auf der Bibliothek basiert, ist die Granularität der Parallelität sehr grob. Derzeit besteht die Architektur vieler Unternehmen aus einer Bibliothek und einer Instanz. Für eine solche Architektur ist die 5.6-Parallelreplikation machtlos. Natürlich gibt es auch die Reihenfolge der Master- und Slave-Transaktionen, was auch für 5.6 ein großes Problem darstellt

Ohne weitere Umschweife, hier sind einige Bilder

4. MySQL 5.7 Parallele Replikation basierend auf Gruppen-Commit

slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based-Modus (Transaktionen in derselben Gruppe [gleiches letztes Commit], keine Sperrkonflikte. In derselben Gruppe dürfen keine Konflikte auftreten, sonst können sie nicht in derselben Gruppe sein)
slave-parallel-type=LOGICAL_CLOCK: Sperrbasierter Modus (selbst wenn die Transaktionen nicht in derselben Gruppe sind, können sie gleichzeitig ausgeführt werden, solange kein Sperrkonflikt [Vorbereitungsphase] zwischen den Transaktionen besteht. Wenn sie nicht in derselben Gruppe sind, gibt es keinen Sperrkonflikt, solange sich die Vorbereitungsphasen von N Transaktionen überschneiden können.)

Das Gruppen-Commit wurde in früheren Artikeln ausführlich beschrieben und wird hier nicht erläutert. Wenn MySQL5.7 eine Gruppe festschreibt, markiert es auch die Transaktionen jeder Gruppe. Jetzt denke ich, dass dies der Bequemlichkeit von MTS dient.

Schauen wir uns zunächst einen Satz von Binärprotokollen an.

zuletzt_committed=0 Sequenznummer=1
zuletzt_festgeschrieben=1 Sequenznummer=2
zuletzt_festgeschrieben=2 Sequenznummer=3
zuletzt_festgeschrieben=3 Sequenznummer=4
zuletzt_festgeschrieben=4 Sequenznummer=5
zuletzt_festgeschrieben=4 Sequenznummer=6
zuletzt_festgeschrieben=4 Sequenznummer=7
zuletzt_festgeschrieben=6 Sequenznummer=8
zuletzt_festgeschrieben=6 Sequenznummer=9
zuletzt_festgeschrieben=9 Sequenznummer=10

4.1 Commit-Parent-basierter Modus

4.2 Sperrbasierter Modus

5. MySQL 8.0 parallele Replikation basierend auf Schreibsatz

Konflikterkennung basierend auf dem Primärschlüssel (binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, Parallelisierung ist möglich, wenn der Primärschlüssel oder der nicht leere eindeutige Schlüssel der geänderten Zeile keinen Konflikt verursacht)
5.7.22 unterstützt auch den Write-Set-Mechanismus

Transaktionsabhängigkeit: binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION

COMMIT_ORDERE: Weiter mit gruppenbasiertem Commit
WRITESET: Transaktionsabhängigkeiten anhand von Schreibsätzen ermitteln
WRITESET_SESSION: Basierend auf dem Schreibsatz, aber Transaktionen in derselben Sitzung haben nicht dasselbe last_committed

Algorithmus zur Transaktionserkennung: transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32

MySQL verfügt über eine Variable zum Speichern des HASH-Werts der übermittelten Transaktion. Die von allen übermittelten Transaktionen geänderten Werte des Primärschlüssels (oder eindeutigen Schlüssels) werden nach dem Hashen mit dem Satz dieser Variablen verglichen, um festzustellen, ob die geänderte Zeile damit in Konflikt steht, und so die Abhängigkeitsbeziehung zu bestimmen.

Die Größe der hier erwähnten Variable kann wie folgt eingestellt werden: binlog_transaction_dependency_history_size

Diese Granularität liegt auf Zeilenebene. Zu diesem Zeitpunkt ist die parallele Granularität feiner und die parallele Geschwindigkeit schneller. In einigen Fällen ist es keine Übertreibung zu sagen, dass die Parallelität des Slaves die des Masters übertrifft (der Master ist ein Single-Thread-Schreibvorgang, und der Slave kann auch parallel wiedergeben).

6. Wie kann die parallele Replikation des Slaves und die Transaktionsausführungsreihenfolge des Masters konsistent gemacht werden?

Nach 5.7.19 können Sie slave_preserve_commit_order = 1 festlegen

Offizielle Erklärung:

Bei Multithread-Slaves stellt die Aktivierung dieser Variable sicher, dass Transaktionen auf dem Slave in derselben Reihenfolge ausgelagert werden, in der sie im Relay-Protokoll des Slaves erscheinen.
Das Festlegen dieser Variable hat keine Auswirkung auf Slaves, für die Multithreading nicht aktiviert ist.
Alle Replikationsthreads (für alle Replikationskanäle, wenn Sie mehrere Replikationskanäle verwenden) müssen gestoppt werden, bevor diese Variable geändert wird.
--log-bin und --log-slave-updates müssen auf dem Slave aktiviert sein.
Außerdem muss --slave-parallel-type auf LOGICAL_CLOCK eingestellt werden.
Sobald ein Multithread-Slave gestartet wurde, können Transaktionen parallel ausgeführt werden.
Wenn „slave_preserve_commit_order“ aktiviert ist, wartet der ausführende Thread, bis alle vorherigen Transaktionen festgeschrieben sind, bevor er ein Commit ausführt.
Während der Slave-Thread darauf wartet, dass andere Worker ihre Transaktionen festschreiben, meldet er seinen Status als „Warten auf Festschreiben der vorhergehenden Transaktion“.

Das allgemeine Implementierungsprinzip lautet: Die Ausführungsphase kann parallel ausgeführt werden und das Leeren des Binärprotokolls wird nacheinander durchgeführt. Wenn die Engine-Schicht festschreibt, wird sie auch in der Warteschlangenreihenfolge gemäß binlog_order_commit abgeschlossen

Mit anderen Worten: Wenn dieser Parameter gesetzt ist, führt der Slave die Parallelisierung wie der Master durch.

Zusammenfassen

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, dass der Inhalt dieses Artikels einen gewissen Lernwert für Ihr Studium oder Ihre Arbeit hat. Wenn Sie Fragen haben, können Sie eine Nachricht hinterlassen. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM.