Oracle släppte nyligen MySQL 8.0.22, och den här nya versionen kom med en ny mekanism för asynkron anslutningsfelövergång. Det tillåter en replik att automatiskt upprätta en asynkron replikeringsanslutning till en ny källa, om dess befintliga misslyckas.
I den här bloggen kommer vi att titta på den här anslutningsfelöver-mekanismen.
Översikt
Den asynkrona failover-mekanismen kan användas för att hålla en replik synkroniserad med en grupp servrar som delar data (Multisource-slav). Den kommer att flytta replikeringsanslutningen till en ny källa när den befintliga källanslutningen misslyckas.
Arbetsprincip
När den befintliga anslutningskällan misslyckas försöker repliken först samma anslutning igen under det antal gånger som anges av MASTER_RETRY_COUNT. Intervallet mellan försöken ställs in av alternativet MASTER_CONNECT_RETRY. När dessa försök är uttömda, tar den asynkrona anslutnings-failover-mekanismen över failover-processen.
Observera att MASTER_RETRY_COUNT som standard är 86400 (1 dag --> 24 timmar) och att MASTER_CONNECT_RETRY standardvärde är 60.
För att säkerställa att den asynkrona anslutningsfelövergångsmekanismen kan aktiveras omedelbart, ställ in MASTER_RETRY_COUNT till ett minimalt antal som bara tillåter ett par försök igen med samma källa, om anslutningsfelet orsakas av ett övergående nätverk avbrott.
Hur man aktiverar asynkron anslutningsfel
- För att aktivera asynkron anslutningsfel för en replikeringskanal, ställ in SOURCE_CONNECTION_AUTO_FAILOVER=1 på CHANGE MASTER TO-satsen för kanalen.
- Vi har två nya funktioner som hjälper till att lägga till och ta bort serverposterna från källlistan.
- asynchronous_connection_failover_add_source (lägg till serverposterna från källlistan)
- asynchronous_connection_failover_delete_source (ta bort serverposterna från källlistan)
När du använder dessa funktioner måste du ange argument som ('kanal', 'värd', port, 'nätverksnamnutrymme', vikt).
Exempel
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)Källservrarna måste konfigureras i tabellen "mysql.replication_asynchronous_connection_failover". Vi kan också använda tabellen "performance_schema.replication_asynchronous_connection_failover" för att se de tillgängliga servrarna i källlistan.
Obs:Om du inte använder någon kanalbaserad replikering, kommer den här failover-mekanismen att fungera. När du kör change master-satsen behöver du inte nämna något kanalnamn. Men se till att GTID är aktiverat på alla servrar.
Användningsfall för produktion
Säg att du har tre PXC-5.7-noder med produktionsdata, som körs bakom ProxySQL. Nu kommer vi att konfigurera den kanalbaserade asynkrona replikeringen under nod 1 (192.168.33.12).
- nod 1 - 192.168.33.12
- nod 2 - 192.168.33.13
- nod 3 - 192.168.33.14
- Läs replika - 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)Arkitekturdiagram
Testfall 1
Vi kommer att lägga till failover-inställningarna:
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 allt bra, jag kan aktivera auto_failover. Låt oss stoppa nod 1 (192.168.33.12) MySQL. ProxySQL kommer att marknadsföra nästa lämpliga master.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceI replikservern
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)IO-tråden är i tillståndet "ansluter". Det betyder att den försöker upprätta anslutningen från den befintliga källan (nod 1) baserat på inställningarna för master_retry_count och master_connect_retry.
Efter några sekunder kan du se att source_host ändrades till nod 2 (192.168.33.13). Nu är övergången klar.
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:Från felloggen
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
När du kör change master-satsen behöver du inte nämna något kanalnamn, oavsett om du använder kanalbaserad replikering eller inte.
Exempel
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)Lägg sedan till failover-inställningarna enligt nedan,
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 ska jag stoppa nod 1 (192.168.33.12).
replikeringsfel
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)Från felloggen
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.Använda ClusterControl
Nu kommer vi att använda ClusterControl för att upprepa den här automatiska failover-processen. Jag har tre noder pxc (5.7) utplacerade av ClusterControl. Jag har en 8.0.22-replikeringsslav under min PXC-nod2 och vi kommer att lägga till denna läsreplika med ClusterControl.
Steg 1
Ställ in den lösenordslösa SSH-inloggningen från ClusterControl-noden för att läsa replikanoden.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Steg 2
Gå till ClusterControl och klicka på rullgardinsikonen och välj alternativet Lägg till replikeringsslav.
Steg 3
Välj sedan alternativet "Befintlig replikeringsslav" och ange den lästa replikens IP och klicka sedan på "Lägg till replikeringsslav".
Steg 4
Ett jobb kommer att triggas och du kan övervaka framstegen på ClusterControl> Loggar> Jobb. När processen är klar kommer slaven att dyka upp på din översiktssida som markerats i följande skärmdump.
Nu kan du kontrollera den aktuella topologin på ClusterControl> Topologi
Replica Auto Failover Process
Nu ska jag göra failover-testning och la till inställningarna nedan till den här funktionen (asynchronous_connection_failover_add_source) i min läsreplika.
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)
Jag ska stoppa nod 2 (192.168.33.13). I ClusterControl är parametern (enable_cluster_autorecovery) aktiverad så att den kommer att främja nästa lämpliga master.
Nu är min nuvarande master nere, så läsreplikan försöker ansluta igen mästaren.
replikeringsfel från läs replik
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)När ClusterControl marknadsför nästa lämpliga master, kommer min läsreplika att ansluta till någon av de tillgängliga klusternoderna.
Den automatiska failover-processen har slutförts och min läsreplika kopplas tillbaka till nod 1 (192.168.33.13) server.
Slutsats
Detta är en av de fantastiska funktionerna i MySQL, det behövs inga manuella ingrepp. Denna automatiska failover-process kan spara lite tid. Och det minskar replikserveravbrottet. Värt att notera, när min gamla master kom tillbaka till rotation, bytte inte replikeringsanslutningen tillbaka till den gamla mastern.