Oracle nedávno vydal MySQL 8.0.22 a tato nová verze přišla s novým mechanismem asynchronního připojení při selhání. Umožňuje replikě automaticky vytvořit asynchronní replikační připojení k novému zdroji v případě, že stávající selže.
V tomto blogu se podíváme na mechanismus převzetí služeb při selhání připojení.
Přehled
Asynchronní mechanismus převzetí služeb při selhání lze použít k udržení repliky synchronizované se skupinou serverů, které sdílejí data (Multisource slave). Pokud stávající zdrojové připojení selže, přesune připojení replikace do nového zdroje.
Pracovní princip
Když selže stávající zdroj připojení, replika se nejprve pokusí o stejné připojení tolikrát, kolikrát je zadáno hodnotou MASTER_RETRY_COUNT. Interval mezi pokusy je nastaven volbou MASTER_CONNECT_RETRY. Když jsou tyto pokusy vyčerpány, mechanismus převzetí služeb při selhání asynchronního připojení převezme proces převzetí služeb při selhání.
Všimněte si, že ve výchozím nastavení je MASTER_RETRY_COUNT 86400 (1 den --> 24 hodin) a výchozí hodnota MASTER_CONNECT_RETRY je 60.
Aby bylo možné okamžitě aktivovat mechanismus převzetí služeb při selhání asynchronního připojení, nastavte MASTER_RETRY_COUNT na minimální číslo, které umožňuje pouze několik pokusů znovu se stejným zdrojem pro případ, že by selhání připojení bylo způsobeno přechodnou sítí. výpadek.
Jak aktivovat asynchronní převzetí služeb při selhání
- Chcete-li aktivovat asynchronní převzetí služeb při selhání pro kanál replikace, nastavte SOURCE_CONNECTION_AUTO_FAILOVER=1 v příkazu CHANGE MASTER TO pro kanál.
- Máme dvě nové funkce, které pomohou přidávat a odstraňovat záznamy serveru ze zdrojového seznamu.
- asynchronous_connection_failover_add_source (přidejte položky serveru ze seznamu zdrojů)
- asynchronous_connection_failover_delete_source (smazat položky serveru ze seznamu zdrojů)
Při používání těchto funkcí musíte zadat argumenty jako ('channel','host',port,'network_namespace',weight).
Příklad
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)Zdrojové servery je třeba nakonfigurovat v tabulce "mysql.replication_asynchronous_connection_failover". Můžeme také použít tabulku "performance_schema.replication_asynchronous_connection_failover" k zobrazení dostupných serverů ve zdrojovém seznamu.
Poznámka:Pokud nepoužíváte žádnou replikaci založenou na kanálu, bude tento mechanismus převzetí služeb při selhání fungovat. Při spouštění příkazu change master není potřeba uvádět žádný název kanálu. Ujistěte se však, že je GTID povoleno na všech serverech.
Případy použití ve výrobě
Řekněme, že máte tři uzly PXC-5.7 s produkčními daty, které běží za ProxySQL. Nyní nakonfigurujeme kanálovou asynchronní replikaci pod uzlem 1 (192.168.33.12).
- uzel 1 – 192.168.33.12
- uzel 2 – 192.168.33.13
- uzel 3 – 192.168.33.14
- Přečíst repliku – 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)Schéma architektury
Testovací případ 1
Přidáme nastavení převzetí služeb při selhání:
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, vše v pořádku, mohu aktivovat auto_failover. Zastavme uzel 1 (192.168.33.12) MySQL. ProxySQL bude podporovat dalšího vhodného mastera.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceNa serveru replik
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)Vlákno IO je ve stavu „připojování“. To znamená, že se pokouší navázat připojení ze stávajícího zdroje (uzel 1) na základě nastavení master_retry_count a master_connect_retry .
Po několika sekundách můžete vidět, že source_host byl změněn na uzel 2 (192.168.33.13). Nyní je převzetí služeb při selhání dokončeno.
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:Z protokolu chyb
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)Testovací případ 2
Během spouštění hlavního příkazu změn není nutné uvádět žádný název kanálu, ať už používáte replikaci založenou na kanálu nebo ne.
Příklad
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)Potom přidejte nastavení převzetí služeb při selhání jako níže
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)Nyní zastavím uzel 1 (192.168.33.12).
Chyba replikace
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)Z protokolu chyb
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.Použití ClusterControl
Nyní použijeme ClusterControl k opakování tohoto procesu automatického převzetí služeb při selhání. Mám tři uzly pxc (5.7) nasazené ClusterControl. Mám 8.0.22 replikační slave pod mým PXC node2 a přidáme tuto čtenou repliku pomocí ClusterControl.
Krok 1
Nastavte přihlášení k SSH bez hesla z uzlu ClusterControl pro čtení replikovaného uzlu.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Krok 2
Přejděte do ClusterControl a klikněte na ikonu rozevíracího seznamu a vyberte možnost Přidat podřízenou replikaci.
Krok 3
Potom vyberte možnost „Existující replikační slave“ a zadejte IP adresu pro čtení repliky a klikněte na „Přidat replikační slave“.
Krok 4
Bude spuštěna úloha a její průběh můžete sledovat v ClusterControl> Protokoly> Úlohy. Po dokončení procesu se slave zobrazí na vaší stránce Přehled, jak je zvýrazněno na následujícím snímku obrazovky.
Nyní můžete zkontrolovat aktuální topologii v ClusterControl> Topologie
Replika automatického převzetí služeb při selhání
Nyní provedu testování převzetí služeb při selhání a do této funkce přidám níže uvedená nastavení (asynchronous_connection_failover_add_source) ve své přečtené replice.
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)
Chystám se zastavit uzel 2 (192.168.33.13). V ClusterControl je parametr (enable_cluster_autorecovery) povolen, takže povýší další vhodný master.
Nyní je můj aktuální hlavní server mimo provoz, takže se čtená replika pokouší připojit mistr.
Chyba replikace při čtení repliky
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)Jakmile ClusterControl povýší dalšího vhodného hlavního serveru, moje čtená replika se připojí k libovolnému z dostupných uzlů clusteru.
Proces automatického převzetí služeb při selhání je dokončen a moje čtená replika se připojí zpět k uzlu 1 (192.168.33.13) server.
Závěr
To je jedna ze skvělých funkcí v MySQL, není potřeba žádný ruční zásah. Tento proces automatického převzetí služeb při selhání vám může ušetřit čas. A snižuje výpadek replikačního serveru. Za zmínku stojí, že když se můj starý master vrátil zpět do rotace, replikační připojení se nepřepnulo zpět na starý master.