Erkunden von MySQL Binlog Server – Ripple

MySQL begrenzt nicht die Anzahl der Slaves, die Sie in einer Replikationstopologie mit dem Master-Server verbinden können. Wenn jedoch die Anzahl der Slaves zunimmt, werden sie die Master-Ressourcen belasten, da die Binärprotokolle an verschiedene Slaves geliefert werden müssen, die mit unterschiedlichen Geschwindigkeiten arbeiten. Wenn die Datenänderung auf dem Master hoch ist, könnte die Bereitstellung von Binärprotokollen allein die Netzwerkschnittstelle des Masters sättigen.

Eine klassische Lösung für dieses Problem ist die Bereitstellung eines Binlog-Servers – eines zwischengeschalteten Proxy-Servers, der zwischen dem Master und seinen Slaves sitzt. Der Binlog-Server wird als Slave des Masters eingerichtet und fungiert wiederum als Master für die ursprüngliche Gruppe von Slaves. Er empfängt Binärprotokoll-Ereignisse vom Master, wendet diese Ereignisse nicht an, sondern liefert sie an alle anderen Slaves. Auf diese Weise wird die Last auf dem Master enorm reduziert und gleichzeitig stellt der Binlog-Server die Binlogs effizienter an Slaves bereit, da er keine andere Datenbankserver-Verarbeitung durchführen muss.

Ripple ist ein von Pavel Ivanov entwickelter Open-Source-Binlog-Server. Ein Blogbeitrag von Percona mit dem Titel MySQL Ripple:The First Impression of a MySQL Binlog Server gibt eine sehr gute Einführung in die Bereitstellung und Verwendung von Ripple. Ich hatte die Gelegenheit, Ripple genauer zu erkunden und wollte meine Beobachtungen in diesem Beitrag teilen.

1. Unterstützung für GTID-basierte Replikation

Ripple unterstützt nur den GTID-Modus und keine datei- und positionsbasierte Replikation. Wenn Ihr Master im Nicht-GTID-Modus läuft, erhalten Sie diesen Fehler von Ripple:

Fehler beim Lesen des Pakets:Fehler beim Lesen des Pakets vom Server:Der Replikationssender-Thread kann nicht im AUTO_POSITION-Modus starten:Dieser Server hat GTID_MODE =OFF statt ON.

Sie können Server_id und UUID für den Ripple-Server mit den Befehlszeilenoptionen angeben:  -ripple_server_id und  -ripple_server_uuid

Beides sind optionale Parameter, und wenn nicht angegeben, verwendet Ripple die Standard-Server-ID=112211 und die UUID wird automatisch generiert.

2. Herstellen einer Verbindung zum Master mithilfe von Replikationsbenutzer und -kennwort

Während Sie sich mit dem Master verbinden, können Sie den Replikationsbenutzer und das Kennwort mit den Befehlszeilenoptionen angeben:

 -ripple_master_user und  -ripple_master_password

3. Verbindungsendpunkt für den Ripple-Server

Sie können die Befehlszeilenoptionen -ripple_server_ports und -ripple_server_address verwenden, um die Verbindungsendpunkte für den Ripple-Server anzugeben. Stellen Sie sicher, dass Sie den über das Netzwerk zugänglichen Hostnamen oder die IP-Adresse Ihres Ripple-Servers als  -rippple_server_address angeben. Andernfalls bindet sich Ripple standardmäßig an localhost und Sie können sich daher nicht remote mit ihm verbinden.

4. Slaves zum Ripple-Server einrichten

Sie können den Befehl CHANGE MASTER TO verwenden, um Ihre Slaves zu verbinden, um vom Ripple-Server zu replizieren.

Um sicherzustellen, dass Ripple das Passwort authentifizieren kann, das Sie verwenden, um sich damit zu verbinden, müssen Sie Ripple starten, indem Sie die Option -ripple_server_password_hash angeben

Zum Beispiel, wenn Sie den Ripple-Server mit dem Befehl starten:

rippled -ripple_datadir=./binlog_server -ripple_master_address= <master ip>  -ripple_master_port=3306 -ripple_master_user=repl -ripple_master_password='password' -ripple_server_ports=15000 -ripple_server_address='172.31.23.201' -ripple_server_password_hash='EF8C75CB6E99A0732D2DE207DAEF65D555BDFB8E'

Sie können den folgenden Befehl CHANGE MASTER TO verwenden, um eine Verbindung vom Slave herzustellen:

CHANGE MASTER TO master_host='172.31.23.201', master_port=15000, master_password=’XpKWeZRNH5#satCI’, master_user=’rep’

Beachten Sie, dass der für den Ripple-Server angegebene Passwort-Hash dem im CHANGE MASTER TO-Befehl verwendeten Textpasswort entspricht. Derzeit authentifiziert sich Ripple nicht basierend auf den Benutzernamen und akzeptiert jeden nicht leeren Benutzernamen, solange das Passwort übereinstimmt.

5. Verwaltung von Ripple-Servern

Es ist möglich, den Ripple-Server mit dem MySQL-Protokoll von jedem Standard-MySQL-Client aus zu überwachen und zu verwalten. Es gibt eine begrenzte Anzahl von unterstützten Befehlen, die Sie direkt im Quellcode auf der mysql-ripple-GitHub-Seite sehen können.

Einige der nützlichen Befehle sind:

• SELECT @@global.gtid_executed; – Um das GTID SET des Ripple-Servers basierend auf seinen heruntergeladenen Binärprotokollen anzuzeigen.
• STOP SLAVE; – Um den Ripple-Server vom Master zu trennen.
• START SLAVE; – Um den Ripple-Server mit dem Master zu verbinden.

Bekannte Probleme und Verbesserungsvorschläge

1. Ich habe keine Option zum Einrichten eines SSL-Replikationskanals von einem Ripple-Server zum Master gesehen

Infolgedessen kann der Ripple-Server keine Verbindung zu einem Master herstellen, der verschlüsselte Verbindungen vorschreibt. Der Versuch, eine Verbindung herzustellen, führt zu folgendem Fehler:

0322 09:01:36.555124 14942 mysql_master_session.cc:164] Failed to connected to host: <Hosname>, port: 3306, err: Failed to connect: Connections using insecure transport are prohibited while --require_secure_transport=ON.

2. Ich konnte den Ripple-Server mit der Semi-Sync-Option nicht zum Laufen bringen

Ich habe den Ripple-Server mit der Option -ripple_semi_sync_slave_enabled=true

Beim Verbinden war der Master in der Lage, den Ripple-Server als semi-sync-fähigen Slave zu erkennen.

mysql> show status like 'rpl%';
------------------------------------------------------
| Variable_name                              | Value |
------------------------------------------------------
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_status                | ON    |
| Rpl_semi_sync_slave_status                 | OFF   |
------------------------------------------------------


Der Versuch, eine Transaktion im Semi-Sync-Modus auszuführen, wartete jedoch auf rpl_semi_sync_master_timeout, das 180000 war

mysql> create database d12;
Query OK, 1 row affected (3 min 0.01 sec)


Ich konnte sehen, dass Semi-Sync am Master ausgeschaltet wurde:

mysql> show status like 'rpl%';
+--------------------------------------------+-------+
| Variable_name                              | Value |
+--------------------------------------------+-------+
| Rpl_semi_sync_master_clients               | 1     |
| Rpl_semi_sync_master_status                | OFF   |
| Rpl_semi_sync_slave_status                 | OFF   |
+--------------------------------------------+-------+

Entsprechender Ausschnitt aus den MySQL-Fehlerprotokollen:

2020-03-21T10:05:56.000612Z 52 [Note] Start binlog_dump to master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [Note] Start semi-sync binlog_dump to slave (server_id: 112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Warning] Timeout waiting for reply of binlog (file: mysql-bin.000010, pos: 350), semi-sync up to file , position 4.
2020-03-21T10:08:55.874044Z 2 [Note] Semi-sync replication switched OFF.


Hier auf der Github-Seite von MySQL Ripple wird ein ähnliches Problem gemeldet.

3. Problem bei Verwendung der parallelen Replikation für die Slaves des Ripple-Servers

Ich habe gesehen, dass der SQL-Thread auf dem Slave oft mit dem Fehler stoppt:

Last_SQL_Error: Cannot execute the current event group in the parallel mode. Encountered event Gtid, relay-log name /mysql_data/relaylogs/relay-log.000005, position 27023962 which prevents execution of this event group in parallel mode. Reason: The master event is logically timestamped incorrectly.

Die Analyse des Relay-Logs und der obigen Position ergab, dass die 'Sequenznummer' der Transaktion zu diesem Zeitpunkt auf 1 zurückgesetzt wurde. Ich habe die Ursache für eine Binlog-Rotation auf dem aufgespürt ursprünglicher Meister. Typischerweise gibt es für direkte Slaves ein Rotationsereignis, aufgrund dessen Relaisprotokolle ebenfalls basierend auf der Rotation des Master-Binärprotokolls rotieren würden. Meine Einschätzung ist, dass solche Bedingungen erkannt werden können und das Zurücksetzen der Sequenznummer von parallelen Threads gehandhabt werden kann. Aber wenn sich die Sequenznummer ohne die Rotation der Relay-Protokolle ändert, sehen wir, dass die parallelen Threads fehlschlagen.

Diese Beobachtung wird als Problem gemeldet:paralleler Slave-Thread-Fehler beim Synchronisieren von Binlog-Server Nr. 26

4. Das Dienstprogramm mysqlbinlog funktioniert nicht mit den vom Ripple-Server erstellten Binärprotokollen

Der Versuch, das Dienstprogramm mysqlbinlog im Binärlog auszuführen, führte zu folgendem Fehler:

ERROR: Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 43, event_type: -106


Dieses Problem wird hier angesprochen:Die binären Protokolldateien können nicht mit dem Dienstprogramm mysqlbinlog geöffnet werden. #25

Es wird vom Autor als bekanntes Problem anerkannt. Ich denke, dass es nützlich wäre, dieses Dienstprogramm für Debugging-Zwecke zu unterstützen.

Das ist vorerst der Bericht von meinem Schnelltest. Ich plane, diesen Blogbeitrag zu aktualisieren, sobald ich auf weitere Erkenntnisse zu Ripple stoße. Insgesamt fand ich es einfach und unkompliziert zu verwenden und hat das Potenzial, ein Standard für Binlog-Server in MySQL-Umgebungen zu werden.