Oracle heeft onlangs MySQL 8.0.22 uitgebracht en deze nieuwe versie kwam met een nieuw failover-mechanisme voor asynchrone verbindingen. Hiermee kan een replica automatisch een asynchrone replicatieverbinding met een nieuwe bron tot stand brengen, voor het geval de bestaande faalt.
In deze blog kijken we naar dit failover-mechanisme voor verbindingen.
Overzicht
Het asynchrone failover-mechanisme kan worden gebruikt om een replica gesynchroniseerd te houden met een groep servers die gegevens delen (Multisource-slave). Het zal de replicatieverbinding naar een nieuwe bron verplaatsen wanneer de bestaande bronverbinding mislukt.
Werkingsprincipe
Als de bestaande verbindingsbron faalt, probeert de replica eerst dezelfde verbinding opnieuw voor het aantal keren dat is opgegeven door de MASTER_RETRY_COUNT. Het interval tussen pogingen wordt ingesteld door de optie MASTER_CONNECT_RETRY. Wanneer deze pogingen zijn uitgeput, neemt het failover-mechanisme van de asynchrone verbinding het failover-proces over.
Merk op dat de MASTER_RETRY_COUNT standaard 86400 (1 dag --> 24 uur) is en de MASTER_CONNECT_RETRY standaardwaarde 60 is.
Om ervoor te zorgen dat het asynchrone failover-mechanisme voor de verbinding snel kan worden geactiveerd, stelt u MASTER_RETRY_COUNT in op een minimaal aantal dat slechts enkele pogingen met dezelfde bron toestaat, voor het geval de verbindingsfout wordt veroorzaakt door een tijdelijk netwerk storing.
Asynchrone verbindingsfailover activeren
- Als u een asynchrone verbindingsfailover voor een replicatiekanaal wilt activeren, stelt u SOURCE_CONNECTION_AUTO_FAILOVER=1 in op de CHANGE MASTER TO-instructie voor het kanaal.
- We hebben twee nieuwe functies, die helpen bij het toevoegen en verwijderen van serveritems uit de bronlijst.
- asynchronous_connection_failover_add_source (voeg de serververmeldingen toe uit de bronlijst)
- asynchronous_connection_failover_delete_source (verwijder de serververmeldingen uit de bronlijst)
Tijdens het gebruik van deze functies moet u de argumenten specificeren zoals ('channel','host',port,'network_namespace',weight).
Voorbeeld
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)De bronservers moeten worden geconfigureerd in de tabel "mysql.replication_asynchronous_connection_failover". We kunnen ook de tabel "performance_schema.replication_asynchronous_connection_failover" gebruiken om de beschikbare servers in de bronlijst te bekijken.
Opmerking:als je geen kanaalgebaseerde replicatie gebruikt, werkt dit failover-mechanisme. Tijdens het uitvoeren van de change master-instructie is het niet nodig om een kanaalnaam te noemen. Maar zorg ervoor dat GTID is ingeschakeld op alle servers.
Gebruiksscenario's voor productie
Stel dat je drie PXC-5.7-knooppunten met productiegegevens hebt, die achter ProxySQL draaien. Nu gaan we de kanaalgebaseerde asynchrone replicatie configureren onder knooppunt 1 (192.168.33.12).
- knooppunt 1 - 192.168.33.12
- knooppunt 2 - 192.168.33.13
- knooppunt 3 - 192.168.33.14
- Replica lezen - 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)Architectuurdiagram
Testcase 1
We gaan de failover-instellingen toevoegen:
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 goed, ik kan de auto_failover activeren. Laten we knooppunt 1 (192.168.33.12) MySQL stoppen. ProxySQL zal de volgende geschikte master promoten.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceIn de replicaserver
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)De IO-thread heeft de status "verbinden". Dit betekent dat het probeert de verbinding tot stand te brengen vanaf de bestaande bron (knooppunt 1) op basis van de master_retry_count en master_connect_retry instellingen.
Na een paar seconden kunt u zien dat de source_host is gewijzigd in node 2 (192.168.33.13). Nu is de failover voltooid.
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:Uit het foutenlogboek
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)Testcase 2
Tijdens het uitvoeren van de change master-instructie is het niet nodig om een kanaalnaam te vermelden, of u nu kanaalgebaseerde replicatie gebruikt of niet.
Voorbeeld
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)Voeg vervolgens de failover-instellingen toe zoals hieronder,
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)Nu ga ik knooppunt 1 (192.168.33.12) stoppen.
Replicatiefout
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)Uit het foutenlogboek
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 gebruiken
Nu gaan we ClusterControl gebruiken om dit automatische failoverproces te herhalen. Ik heb drie knooppunten pxc (5.7) geïmplementeerd door ClusterControl. Ik heb een 8.0.22-replicatieslave onder mijn PXC-node2 en we gaan deze leesreplica toevoegen met ClusterControl.
Stap 1
Stel de wachtwoordloze SSH-aanmelding in vanaf het ClusterControl-knooppunt om het replicaknooppunt te lezen.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Stap 2
Ga naar ClusterControl en klik op het vervolgkeuzepictogram en selecteer de optie Replicatie-slave toevoegen.
Stap 3
Kies vervolgens de optie "Bestaande replicatieslave" en voer het gelezen replica-IP in en klik vervolgens op "Replicatieslave toevoegen".
Stap 4
Er wordt een taak geactiveerd en u kunt de voortgang volgen via ClusterControl> Logboeken> Taken. Zodra het proces is voltooid, wordt de slave weergegeven op uw overzichtspagina, zoals gemarkeerd in de volgende schermafbeelding.
Nu kunt u de huidige topologie controleren via ClusterControl> Topologie
Replica automatisch failoverproces
Nu ga ik failover-testen doen en de onderstaande instellingen toevoegen aan deze functie (asynchronous_connection_failover_add_source) in mijn leesreplica.
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)
Ik ga knooppunt 2 stoppen (192.168.33.13). In ClusterControl is de parameter (enable_cluster_autorecovery) ingeschakeld, zodat deze de volgende geschikte master zal promoten.
Mijn huidige master is nu offline, dus de gelezen replica probeert opnieuw verbinding te maken de meester.
Replicatiefout van leesreplica
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)Zodra de ClusterControl de volgende geschikte master promoot, zal mijn leesreplica verbinding maken met een van de beschikbare clusterknooppunten.
Het automatische failoverproces is voltooid en mijn leesreplica is teruggekoppeld naar knooppunt 1 (192.168.33.13) server.
Conclusie
Dit is een van de geweldige functies in MySQL, er is geen handmatige tussenkomst nodig. Dit automatische failoverproces kan u wat tijd besparen. En het vermindert de uitval van de replicaserver. Het is vermeldenswaard dat toen mijn oude master weer in rotatie kwam, de replicatieverbinding niet terugging naar de oude master.