Oracle ha recentemente rilasciato MySQL 8.0.22 e questa nuova versione include un nuovo meccanismo di failover della connessione asincrona. Consente a una replica di stabilire automaticamente una connessione di replica asincrona a una nuova origine, nel caso in cui quella esistente si guasta.
In questo blog, esamineremo questo meccanismo di failover della connessione.
Panoramica
Il meccanismo di failover asincrono può essere utilizzato per mantenere una replica sincronizzata con un gruppo di server che condividono i dati (slave multisorgente). Sposterà la connessione di replica su una nuova origine quando la connessione di origine esistente non riesce.
Principio di lavoro
Quando l'origine della connessione esistente non riesce, la replica prima riprova la stessa connessione per il numero di volte specificato da MASTER_RETRY_COUNT. L'intervallo tra i tentativi è impostato dall'opzione MASTER_CONNECT_RETRY. Quando questi tentativi sono esauriti, il meccanismo di failover della connessione asincrona assume il controllo del processo di failover.
Nota che per impostazione predefinita MASTER_RETRY_COUNT è 86400 (1 giorno --> 24 ore) e il valore predefinito MASTER_CONNECT_RETRY è 60.
Per garantire che il meccanismo di failover della connessione asincrona possa essere attivato tempestivamente, impostare MASTER_RETRY_COUNT su un numero minimo che consenta solo alcuni tentativi con la stessa sorgente, nel caso in cui l'interruzione della connessione sia causata da una rete transitoria interruzione.
Come attivare il failover della connessione asincrona
- Per attivare il failover della connessione asincrona per un canale di replica, impostare SOURCE_CONNECTION_AUTO_FAILOVER=1 sull'istruzione CHANGE MASTER TO per il canale.
- Abbiamo due nuove funzioni, che aiuteranno ad aggiungere ed eliminare le voci del server dall'elenco dei sorgenti.
- connessione_asincrona_failover_add_source (aggiungi le voci del server dall'elenco dei sorgenti)
- connessione_asincrona_failover_delete_source (elimina le voci del server dall'elenco dei sorgenti)
Durante l'utilizzo di queste funzioni, è necessario specificare argomenti come ('channel','host',port,'network_namespace',weight).
Esempio
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)I server di origine devono essere configurati nella tabella "mysql.replication_asynchronous_connection_failover". Possiamo anche utilizzare la tabella "performance_schema.replication_asynchronous_connection_failover" per visualizzare i server disponibili nell'elenco dei sorgenti.
Nota:se non si utilizza alcuna replica basata sul canale, questo meccanismo di failover funzionerà. Durante l'esecuzione dell'istruzione change master, non è necessario menzionare alcun nome di canale. Ma assicurati che GTID sia abilitato su tutti i server.
Casi d'uso della produzione
Supponiamo che tu abbia tre nodi PXC-5.7 con dati di produzione, in esecuzione dietro ProxySQL. Ora configureremo la replica asincrona basata sul canale nel nodo 1 (192.168.33.12).
- nodo 1 - 192.168.33.12
- nodo 2 - 192.168.33.13
- nodo 3 - 192.168.33.14
- Leggi 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)Diagramma architettonico
Caso di prova 1
Aggiungeremo le impostazioni di failover:
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 tutto bene, posso attivare l'auto_failover. Fermiamo il nodo 1 (192.168.33.12) MySQL. ProxySQL promuoverà il prossimo master adatto.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceNel server di replica
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)Il thread IO è in stato di "connessione". Ciò significa che sta tentando di stabilire la connessione dall'origine esistente (nodo 1) in base alle impostazioni master_retry_count e master_connect_retry.
Dopo alcuni secondi, puoi vedere che source_host è stato modificato nel nodo 2 (192.168.33.13). Ora il failover è terminato.
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:Dal registro errori
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)Caso di prova 2
Durante l'esecuzione dell'istruzione change master, non è necessario menzionare alcun nome di canale, indipendentemente dal fatto che tu stia utilizzando la replica basata sul canale o meno.
Esempio
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)Quindi aggiungi le impostazioni di failover come di seguito,
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)Ora fermerò il nodo 1 (192.168.33.12).
Errore di replica
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)Dal registro errori
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.Utilizzo di ClusterControl
Ora useremo ClusterControl per ripetere questo processo di failover automatico. Ho tre nodi pxc (5.7) distribuiti da ClusterControl. Ho uno slave di replica 8.0.22 sotto il mio nodo PXC2 e aggiungeremo questa replica di lettura utilizzando ClusterControl.
Fase 1
Imposta l'accesso SSH senza password dal nodo ClusterControl per leggere il nodo di replica.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Fase 2
Vai su ClusterControl e fai clic sull'icona a discesa e seleziona l'opzione Aggiungi replica slave.
Fase 3
Quindi scegli l'opzione "Slave di replica esistente" e inserisci l'IP di replica di lettura, quindi fai clic su "Aggiungi slave di replica".
Fase 4
Verrà attivato un lavoro ed è possibile monitorare l'avanzamento in ClusterControl> Registri> Lavori. Una volta completato il processo, lo slave verrà visualizzato nella tua pagina Panoramica come evidenziato nello screenshot seguente.
Ora puoi controllare la topologia corrente in ClusterControl> Topologia
Replica processo di failover automatico
Ora eseguirò i test di failover e aggiungerò le impostazioni seguenti a questa funzione (asynchronous_connection_failover_add_source) nella mia replica di lettura.
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)
Sto per interrompere il nodo 2 (192.168.33.13). In ClusterControl, il parametro (enable_cluster_autorecovery) è abilitato, quindi promuoverà il prossimo master adatto.
Ora il mio master attuale è inattivo, quindi la replica di lettura sta tentando di connettersi di nuovo il maestro.
Errore di replica dalla replica di lettura
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)Una volta che ClusterControl promuove il prossimo master adatto, la mia replica di lettura si connetterà a uno qualsiasi dei nodi del cluster disponibili.
Il processo di failover automatico è completato e la mia replica di lettura è tornata al nodo 1 (192.168.33.13) server.
Conclusione
Questa è una delle grandi funzionalità di MySQL, non è necessario alcun intervento manuale. Questo processo di failover automatico può farti risparmiare tempo. E riduce l'interruzione del server di replica. Vale la pena notare che quando il mio vecchio master tornava alla rotazione, la connessione di replica non tornava al vecchio master.
