Eine kurze Analyse der parallelen MySQL-Replikation

01 Das Konzept der parallelen Replikation

In der Master-Slave-Replikationsarchitektur von MySQL werden häufig viele SQL-Anweisungen gleichzeitig in der Masterdatenbank ausgeführt. Solange diese SQL-Anweisungen keine Sperrwartezeiten erzeugen, ist es kein Problem, mehrere SQL-Threads gleichzeitig auszuführen.

Wir wissen, dass die MySQL-Slave-Datenbank IO_thread verwendet, um das Binärprotokoll aus der Master-Datenbank abzurufen, es dann lokal speichert und als Relay-Protokoll auf die Festplatte schreibt und diese Relay-Protokolle über sql_thread anwendet.

In Versionen vor MySQL 5.6 gab es nur einen SQL-Thread, wenn mehrere Threads gleichzeitig SQL auf der Masterdatenbank ausführten. In einigen Szenarien mit hohem TPS kam es zu erheblichen Verzögerungen bei der Masterdatenbank. Um dieses Problem zu lösen, hat MySQL sql_thread in mehrere Worker weiterentwickelt und die Transaktionen im Relay-Protokoll parallel auf der Slave-Seite angewendet, wodurch die Anwendungsgeschwindigkeit des Relay-Protokolls erhöht und die Replikationsverzögerung verringert wurde. Hier kommt die parallele Replikation ins Spiel.

In MySQL werden Replikationsthreads durch den Parameter slave_parallel_workers gesteuert. Normalerweise ist es auf einer Maschine mit 8 GB Speicher und 8-Kern-CPU angemessen, diesen Wert auf 8 zu setzen. Wenn Ihre CPU eine hohe Anzahl von Kernen hat, können Sie ihn auf eine Zahl zwischen 8 und 16 einstellen.

mysql> Variablen wie „slave_parallel_workers“ anzeigen;
+------------------------+----------+
| Variablenname | Wert |
+------------------------+----------+
| Sklaven_Parallelarbeiter | 8 |
+------------------------+----------+
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

02 Entwicklung der parallelen Replikation

Der Kern der parallelen Replikation besteht darin, dass es bei gleichzeitig ausgeführten SQL-Anweisungen zu keinen Sperrkonflikten kommt.

In MySQL Version 5.6 besteht die von MySQL unterstützte Granularität darin, Relay-Protokolle parallel nach Datenbanken auszuführen. Diese Methode kann einige Probleme lösen, da SQL auf verschiedenen Datenbanken den Inhalt derselben Zeile in der Tabelle definitiv nicht ändert. Auf diese Weise kommt es zu keinen Sperrkonflikten. Diese Methode der parallelen Replikation eignet sich besser für Szenarien, in denen einige Datenbanken gleichmäßig verteilt sind und die einzelnen Datenbanken mit ähnlicher Häufigkeit verwendet werden. Wenn die Daten Ihres Unternehmens in einer Hot Table konzentriert sind, degeneriert die parallele Replikation in diesem Fall zu einer Single-Thread-Replikation.

Anschließend wurden einige Verbesserungen an der parallelen Replikation in MariaDB vorgenommen. Der Ansatz ist:

1. Transaktionen, die parallel an die Master-Datenbank übermittelt werden können, d. h. Transaktionen, die in die Redo-Log-Commit-Phase eingetreten sind, können auch parallel an die Slave-Datenbank übermittelt werden. Daher werden parallel an die Master-Datenbank übermittelte Transaktionen durch eine Commit-ID identifiziert. Die Commit-ID der nächsten Gruppe paralleler Transaktionen ist die Commit-ID+1 dieser Gruppe.

2. Schreiben Sie die Commit-ID aller Transaktionen in Binlog

3. Wenn Sie Binlog aus der Datenbank anwenden, teilen Sie alle Binlogs entsprechend der Commit-ID in verschiedene Worker auf

4. Nachdem alle Transaktionen der Commit-ID in dieser Gruppe in der Slave-Datenbank festgeschrieben wurden, wird der nächste Transaktionsstapel ausgeführt.

Mit dieser Methode lässt sich die Geschwindigkeit beim Anwenden von Relay-Protokollen vom Slave erheblich steigern. Das Problem besteht jedoch darin, dass, während der Slave den vorherigen Satz von Transaktionen anwendet, der nächste Satz von Transaktionen wartet, selbst wenn einige der Worker im vorherigen Satz inaktiv sind. In die Masterdatenbank werden möglicherweise ständig Daten geschrieben. Infolgedessen stimmen die Systemdurchsatzraten von Master- und Slaveknoten nicht überein, und der Durchsatz der Masterdatenbank ist viel höher als der der Slavedatenbank.

Die parallele Replikation von MySQL 5.7 wird auf der Grundlage von MariaDB verbessert. Wir wissen, dass, wenn die Transaktion in die Redo-Log-Vorbereitungsphase eintritt, dies aufgrund der WAL-Technologie bedeutet, dass die Transaktion die Konflikterkennungsphase durchlaufen hat. Bei der parallelen Replikation von MySQL 5.7 werden alle Transaktionen in der Redo-Log-Vorbereitungsphase auf der Masterdatenbank und alle Transaktionen nach dieser Phase, d. h. alle Transaktionen in der Redo-Log-Commit-Phase, parallel auf der Slavedatenbank ausgeführt. Dadurch wird unnötiges Warten der Worker-Threads reduziert.

Hier müssen noch zwei weitere Parameter besprochen werden.

• Der Parameter binnlog_group_commit_sync_delay gibt an, wie viele Mikrosekunden es dauert, fsync aufzurufen, nachdem die Redo-Log-Vorbereitungsphase abgeschlossen ist.
• Der Parameter binlog_group_commit_sync_no_delay_count gibt an, wie oft Redo-Log-Prepare:Write-Operationen akkumuliert werden, bevor fsync aufgerufen wird.

Diese beiden Parameter werden verwendet, um die Zeit vom Binlog-Schreiben bis zum Fsync absichtlich zu verlängern und so die Anzahl der Binlog-Schreibvorgänge zu reduzieren. In der parallelen Replikationsstrategie von MySQL 5.7 können sie verwendet werden, um mehr „Transaktionen gleichzeitig in der Vorbereitungsphase“ zu erstellen. Dadurch wird die Parallelität der Standby-Datenbankreplikation erhöht.

Sie können „absichtlich“ dafür sorgen, dass die Commits der primären Datenbank langsamer erfolgen und die Ausführung der Standby-Datenbank schneller wird. Beim Umgang mit Verzögerungen bei der Standby-Datenbank in MySQL 5.7 können Sie die Anpassung dieser beiden Parameterwerte in Betracht ziehen, um die Parallelität der Replikation der Standby-Datenbank zu verbessern.

Oben finden Sie eine kurze Analyse der Details der parallelen MySQL-Replikation. Weitere Informationen zur parallelen MySQL-Replikation finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!