Oracle hat kürzlich MySQL 8.0.22 veröffentlicht, und diese neue Version kam mit einem neuen Failover-Mechanismus für asynchrone Verbindungen. Es ermöglicht einem Replikat, automatisch eine asynchrone Replikationsverbindung zu einer neuen Quelle herzustellen, falls die vorhandene ausfällt.
In diesem Blog werden wir uns diesen Verbindungs-Failover-Mechanismus ansehen.
Übersicht
Der asynchrone Failover-Mechanismus kann verwendet werden, um ein Replikat mit einer Gruppe von Servern zu synchronisieren, die Daten gemeinsam nutzen (Multisource-Slave). Es verschiebt die Replikationsverbindung zu einer neuen Quelle, wenn die vorhandene Quellverbindung fehlschlägt.
Arbeitsprinzip
Wenn die vorhandene Verbindungsquelle fehlschlägt, versucht das Replikat zunächst dieselbe Verbindung so oft, wie durch MASTER_RETRY_COUNT angegeben. Das Intervall zwischen den Versuchen wird durch die Option MASTER_CONNECT_RETRY festgelegt. Wenn diese Versuche erschöpft sind, übernimmt der Failover-Mechanismus für asynchrone Verbindungen den Failover-Prozess.
Beachten Sie, dass der MASTER_RETRY_COUNT standardmäßig 86400 (1 Tag --> 24 Stunden) und der MASTER_CONNECT_RETRY-Standardwert 60 ist.
Um sicherzustellen, dass der Failover-Mechanismus für asynchrone Verbindungen sofort aktiviert werden kann, setzen Sie MASTER_RETRY_COUNT auf eine minimale Zahl, die nur wenige Wiederholungsversuche mit derselben Quelle zulässt, falls der Verbindungsausfall durch ein vorübergehendes Netzwerk verursacht wird Ausfall.
So aktivieren Sie das asynchrone Verbindungs-Failover
- Um asynchrones Verbindungs-Failover für einen Replikationskanal zu aktivieren, setzen Sie SOURCE_CONNECTION_AUTO_FAILOVER=1 in der CHANGE MASTER TO-Anweisung für den Kanal.
- Wir haben zwei neue Funktionen, die beim Hinzufügen und Löschen von Servereinträgen aus der Quellenliste helfen werden.
- asynchronous_connection_failover_add_source (Fügen Sie die Servereinträge aus der Quellliste hinzu)
- asynchronous_connection_failover_delete_source (löscht die Servereinträge aus der Quellliste)
Während Sie diese Funktionen verwenden, müssen Sie die Argumente wie ('channel','host',port,'network_namespace',weight) angeben.
Beispiel
mysql> select asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100);
+----------------------------------------------------------------------------------------+
| asynchronous_connection_failover_add_source('testing', '192.168.33.12', 3306, '', 100) |
+----------------------------------------------------------------------------------------+
| The UDF asynchronous_connection_failover_add_source() executed successfully. |
+----------------------------------------------------------------------------------------+
1 row in set (0.00 sec)Die Quellserver müssen in der Tabelle "mysql.replication_asynchronous_connection_failover" konfiguriert werden. Wir können auch die Tabelle "performance_schema.replication_asynchronous_connection_failover" verwenden, um die verfügbaren Server in der Quellliste anzuzeigen.
Hinweis:Wenn Sie keine kanalbasierte Replikation verwenden, funktioniert dieser Failover-Mechanismus. Beim Ausführen der Change-Master-Anweisung muss kein Kanalname angegeben werden. Stellen Sie jedoch sicher, dass GTID auf allen Servern aktiviert ist.
Anwendungsfälle für die Produktion
Angenommen, Sie haben drei PXC-5.7-Knoten mit Produktionsdaten, die hinter ProxySQL ausgeführt werden. Jetzt werden wir die kanalbasierte asynchrone Replikation unter Knoten 1 (192.168.33.12) konfigurieren.
- Knoten 1 - 192.168.33.12
- Knoten 2 - 192.168.33.13
- Knoten 3 - 192.168.33.14
- Read Replica – 192.168.33.15
mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=6 for channel "prod_replica";
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> start replica for channel 'prod_replica';
Query OK, 0 rows affected (0.00 sec)Architekturdiagramm
Testfall 1
Wir werden die Failover-Einstellungen hinzufügen:
mysql> select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);
+---------------------------------------------------------------------------------------------+
| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100) |
+---------------------------------------------------------------------------------------------+
| The UDF asynchronous_connection_failover_add_source() executed successfully. |
+---------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);
+--------------------------------------------------------------------------------------------+
| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80) |
+--------------------------------------------------------------------------------------------+
| The UDF asynchronous_connection_failover_add_source() executed successfully. |
+--------------------------------------------------------------------------------------------+
1 row in set (0.01 sec)
mysql> select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);
+--------------------------------------------------------------------------------------------+
| asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60) |
+--------------------------------------------------------------------------------------------+
| The UDF asynchronous_connection_failover_add_source() executed successfully. |
+--------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> select * from mysql.replication_asynchronous_connection_failover;
+-------------------+---------------+------+-------------------+--------+
| Channel_name | Host | Port | Network_namespace | Weight |
+-------------------+---------------+------+-------------------+--------+
| prod_replica | 192.168.33.12 | 3306 | | 100 |
| prod_replica | 192.168.33.13 | 3306 | | 80 |
| prod_replica | 192.168.33.14 | 3306 | | 60 |
+-------------------+---------------+------+-------------------+--------+
3 rows in set (0.00 sec)Ok alles gut, ich kann das auto_failover aktivieren. Stoppen wir Knoten 1 (192.168.33.12) MySQL. ProxySQL befördert den nächsten geeigneten Master.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceIm Replica-Server
mysql> show replica status\G
*************************** 1. row ***************************
Slave_IO_State: Reconnecting after a failed master event read
Master_Host: 192.168.33.12
Master_User: repl
Master_Port: 3306
Connect_Retry: 6
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 1143
Relay_Log_File: relay-bin-testing.000006
Relay_Log_Pos: 1352
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Connecting
Slave_SQL_Running: Yes
Replicate_Do_DB:
Last_IO_Error: error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)Der IO-Thread befindet sich im Status "Verbinden". Dies bedeutet, dass versucht wird, die Verbindung von der vorhandenen Quelle (Knoten 1) basierend auf den Einstellungen master_retry_count und master_connect_retry herzustellen.
Nach einigen Sekunden können Sie sehen, dass source_host auf Knoten 2 (192.168.33.13) geändert wurde. Jetzt ist das Failover abgeschlossen.
mysql> show replica status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.33.13
Master_User: repl
Master_Port: 3306
Connect_Retry: 6
Master_Log_File: binlog.000004
Read_Master_Log_Pos: 1162
Relay_Log_File: relay-bin-testing.000007
Relay_Log_Pos: 487
Relay_Master_Log_File: binlog.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Last_IO_Error:Aus dem Fehlerprotokoll
2020-10-29T22:22:05.679951Z 54 [ERROR] [MY-010584] [Repl] Slave I/O for channel 'prod_replica': error reconnecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003
2020-10-29T22:22:05.681121Z 58 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2020-10-29T22:22:05.682830Z 58 [System] [MY-010562] [Repl] Slave I/O thread for channel 'prod_replica': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 2660
2020-10-29T22:22:05.685175Z 58 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 31b5b7d0-1a25-11eb-8076-080027090068.
(END)Testfall 2
Während der Ausführung der Change-Master-Anweisung muss kein Kanalname angegeben werden, unabhängig davon, ob Sie die kanalbasierte Replikation verwenden oder nicht.
Beispiel
mysql> change master to master_user='repl',master_password='[email protected]',master_host='192.168.33.12',master_auto_position=1,source_connection_auto_failover=1,master_retry_count=3,master_connect_retry=10;
Query OK, 0 rows affected, 2 warnings (0.01 sec)
mysql> start replica;
Query OK, 0 rows affected (0.00 sec)Fügen Sie dann die Failover-Einstellungen wie unten hinzu,
select asynchronous_connection_failover_add_source('', '192.168.33.12', 3306, '', 100);
select asynchronous_connection_failover_add_source('', '192.168.33.13', 3306, '', 80);
select asynchronous_connection_failover_add_source('', '192.168.33.14', 3306, '', 60);
mysql> select * from mysql.replication_asynchronous_connection_failover;
+--------------+---------------+------+-------------------+--------+
| Channel_name | Host | Port | Network_namespace | Weight |
+--------------+---------------+------+-------------------+--------+
| | 192.168.33.12 | 3306 | | 100 |
| | 192.168.33.13 | 3306 | | 80 |
| | 192.168.33.14 | 3306 | | 60 |
+--------------+---------------+------+-------------------+--------+
3 rows in set (0.00 sec)Jetzt stoppe ich Knoten 1 (192.168.33.12).
Replikationsfehler
Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 10 retries: 2 message: Can't connect to MySQL server on '192.168.33.12' (111)Aus dem Fehlerprotokoll
2020-10-30T00:38:03.471482Z 27 [ERROR] [MY-010584] [Repl] Slave I/O for channel '': error connecting to master '[email protected]:3306' - retry-time: 10 retries: 3 message: Can't connect to MySQL server on '192.168.33.12' (111), Error_code: MY-002003
2020-10-30T00:38:03.472002Z 29 [Warning] [MY-010897] [Repl] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
2020-10-30T00:38:03.473493Z 29 [System] [MY-010562] [Repl] Slave I/O thread for channel '': connected to master '[email protected]:3306',replication started in log 'FIRST' at position 234
2020-10-30T00:38:03.475471Z 29 [Warning] [MY-010549] [Repl] The master's UUID has changed, although this should not happen unless you have changed it manually. The old UUID was 1ff8a919-1a39-11eb-a27a-080027090068.ClusterControl verwenden
Nun verwenden wir ClusterControl, um diesen automatischen Failover-Prozess zu wiederholen. Ich habe drei Knoten pxc (5.7), die von ClusterControl bereitgestellt werden. Ich habe einen 8.0.22-Replikations-Slave unter meinem PXC-Knoten2 und wir werden diese Lesereplikate mithilfe von ClusterControl hinzufügen.
Schritt 1
Richten Sie die kennwortlose SSH-Anmeldung vom ClusterControl-Knoten zum Read Replica-Knoten ein.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Schritt 2
Gehen Sie zu ClusterControl und klicken Sie auf das Dropdown-Symbol und wählen Sie die Option Replikations-Slave hinzufügen.
Schritt 3
Wählen Sie dann die Option „Existing Replication Slave“ und geben Sie die Read Replica IP ein und klicken Sie dann auf „Add Replication Slave“.
Schritt 4
Ein Job wird ausgelöst und Sie können den Fortschritt unter ClusterControl> Logs> Jobs überwachen. Sobald der Vorgang abgeschlossen ist, wird der Slave auf Ihrer Übersichtsseite angezeigt, wie im folgenden Screenshot hervorgehoben.
Jetzt können Sie die aktuelle Topologie unter ClusterControl> Topology
überprüfen
Replica Auto Failover Process
Jetzt werde ich Failover-Tests durchführen und die folgenden Einstellungen zu dieser Funktion (asynchronous_connection_failover_add_source) in meiner Read Replica hinzufügen.
select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.12', 3306, '', 100);
select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.13', 3306, '', 80);
select asynchronous_connection_failover_add_source('prod_replica', '192.168.33.14', 3306, '', 60);
mysql> select * from mysql.replication_asynchronous_connection_failover;
+--------------+---------------+------+-------------------+--------+
| Channel_name | Host | Port | Network_namespace | Weight |
+--------------+---------------+------+-------------------+--------+
| prod_replica | 192.168.33.12 | 3306 | | 100 |
| prod_replica | 192.168.33.13 | 3306 | | 80 |
| prod_replica | 192.168.33.14 | 3306 | | 60 |
+--------------+---------------+------+-------------------+--------+
3 rows in set (0.00 sec)
mysql> select CONNECTION_RETRY_INTERVAL,CONNECTION_RETRY_COUNT,SOURCE_CONNECTION_AUTO_FAILOVER from performance_schema.replication_connection_conf
iguration;
+---------------------------+------------------------+---------------------------------+
| CONNECTION_RETRY_INTERVAL | CONNECTION_RETRY_COUNT | SOURCE_CONNECTION_AUTO_FAILOVER |
+---------------------------+------------------------+---------------------------------+
| 6 | 3 | 1 |
+---------------------------+------------------------+---------------------------------+
1 row in set (0.00 sec)
Ich werde Knoten 2 (192.168.33.13) stoppen. In ClusterControl ist der Parameter (enable_cluster_autorecovery) aktiviert, sodass er den nächsten geeigneten Master befördert.
Jetzt ist mein aktueller Master ausgefallen, sodass die Read Replica erneut versucht, eine Verbindung herzustellen der Meister.
Replikationsfehler von Read Replica
Last_IO_Error: error connecting to master '[email protected]:3306' - retry-time: 6 retries: 2 message: Can't connect to MySQL server on '192.168.33.13' (111)Sobald die ClusterControl den nächsten geeigneten Master hochstuft, verbindet sich mein Lesereplikat mit einem der verfügbaren Cluster-Knoten.
Der automatische Failover-Prozess ist abgeschlossen und meine Read Replica wird wieder mit Knoten 1 verbunden (192.168.33.13)-Server.
Fazit
Dies ist eine der großartigen Funktionen von MySQL, es ist kein manueller Eingriff erforderlich. Dieser automatische Failover-Prozess kann Ihnen Zeit sparen. Und es reduziert den Ausfall des Replikatservers. Erwähnenswert ist, dass die Replikationsverbindung nicht zum alten Master zurückwechselte, als mein alter Master wieder in Rotation ging.
