Oracle a récemment publié MySQL 8.0.22, et cette nouvelle version est livrée avec un nouveau mécanisme de basculement de connexion asynchrone. Il permet à une réplique d'établir automatiquement une connexion de réplication asynchrone vers une nouvelle source, en cas d'échec de la connexion existante.
Dans ce blog, nous examinerons ce mécanisme de basculement de connexion.
Aperçu
Le mécanisme de basculement asynchrone peut être utilisé pour maintenir une réplique synchronisée avec un groupe de serveurs qui partagent des données (esclave multisource). Il déplacera la connexion de réplication vers une nouvelle source en cas d'échec de la connexion source existante.
Principe de fonctionnement
Lorsque la source de connexion existante échoue, le réplica tente d'abord la même connexion le nombre de fois spécifié par MASTER_RETRY_COUNT. L'intervalle entre les tentatives est défini par l'option MASTER_CONNECT_RETRY. Lorsque ces tentatives sont épuisées, le mécanisme de basculement de connexion asynchrone prend le relais du processus de basculement.
Notez que par défaut, MASTER_RETRY_COUNT est 86400 (1 jour --> 24 heures) et la valeur par défaut MASTER_CONNECT_RETRY est 60.
Pour vous assurer que le mécanisme de basculement de connexion asynchrone peut être activé rapidement, définissez MASTER_RETRY_COUNT sur un nombre minimal qui permet juste quelques nouvelles tentatives avec la même source, au cas où l'échec de la connexion serait causé par un réseau transitoire panne.
Comment activer le basculement de connexion asynchrone
- Pour activer le basculement de connexion asynchrone pour un canal de réplication, définissez SOURCE_CONNECTION_AUTO_FAILOVER=1 sur l'instruction CHANGE MASTER TO pour le canal.
- Nous avons deux nouvelles fonctions, qui aideront à ajouter et supprimer les entrées de serveur de la liste source.
- asynchronous_connection_failover_add_source (ajoute les entrées du serveur à partir de la liste source)
- asynchronous_connection_failover_delete_source (supprime les entrées de serveur de la liste des sources)
Lors de l'utilisation de ces fonctions, vous devez spécifier des arguments tels que ('channel','host',port,'network_namespace',weight).
Exemple
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)Les serveurs sources doivent être configurés dans la table "mysql.replication_asynchronous_connection_failover". Nous pouvons également utiliser la table "performance_schema.replication_asynchronous_connection_failover" pour afficher les serveurs disponibles dans la liste source.
Remarque :si vous n'utilisez aucune réplication basée sur le canal, ce mécanisme de basculement fonctionnera. Lors de l'exécution de l'instruction change master, il n'est pas nécessaire de mentionner un nom de canal. Mais assurez-vous que GTID est activé sur tous les serveurs.
Cas d'utilisation de la production
Disons que vous avez trois nœuds PXC-5.7 avec des données de production, exécutés derrière ProxySQL. Maintenant, nous allons configurer la réplication asynchrone basée sur le canal sous le nœud 1 (192.168.33.12).
- noeud 1 - 192.168.33.12
- nœud 2 - 192.168.33.13
- noeud 3 - 192.168.33.14
- Lire le réplica - 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 d'architecture
Cas de test 1
Nous allons ajouter les paramètres de basculement :
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 tout va bien, je peux activer l'auto_failover. Arrêtons le nœud 1 (192.168.33.12) MySQL. ProxySQL promouvra le prochain maître approprié.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceDans le serveur de réplication
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)Le thread IO est dans l'état "connecting". Cela signifie qu'il essaie d'établir la connexion à partir de la source existante (nœud 1) en fonction des paramètres master_retry_count et master_connect_retry .
Après quelques secondes, vous pouvez voir que le source_host a été remplacé par le nœud 2 (192.168.33.13). Le basculement est maintenant terminé.
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:Depuis le journal des erreurs
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)Cas de test 2
Lors de l'exécution de l'instruction change master, il n'est pas nécessaire de mentionner un nom de canal, que vous utilisiez ou non la réplication basée sur le canal.
Exemple
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)Ensuite, ajoutez les paramètres de basculement comme ci-dessous,
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)Maintenant, je vais arrêter le nœud 1 (192.168.33.12).
Erreur de réplication
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)À partir du journal des erreurs
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.Utiliser ClusterControl
Nous allons maintenant utiliser ClusterControl pour répéter ce processus de basculement automatique. J'ai trois nœuds pxc (5.7) déployés par ClusterControl. J'ai un esclave de réplication 8.0.22 sous mon nœud PXC2 et nous allons ajouter ce réplica en lecture à l'aide de ClusterControl.
Étape 1
Configurez la connexion SSH sans mot de passe à partir du nœud ClusterControl pour lire le nœud de réplique.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Étape 2
Allez à ClusterControl et cliquez sur l'icône déroulante et sélectionnez l'option Ajouter un esclave de réplication.
Étape 3
Ensuite, choisissez l'option "Esclave de réplication existant" et entrez l'adresse IP du réplica en lecture, puis cliquez sur "Ajouter un esclave de réplication".
Étape 4
Une tâche sera déclenchée et vous pouvez surveiller la progression dans ClusterControl> Journaux> Tâches. Une fois le processus terminé, l'esclave apparaîtra dans votre page d'aperçu, comme indiqué dans la capture d'écran suivante.
Vous pouvez maintenant vérifier la topologie actuelle dans ClusterControl > Topologie
Processus de basculement automatique du réplica
Maintenant, je vais faire des tests de basculement et ajouter les paramètres ci-dessous à cette fonction (asynchronous_connection_failover_add_source) dans mon réplica en lecture.
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)
Je vais arrêter le nœud 2 (192.168.33.13). Dans ClusterControl, le paramètre (enable_cluster_autorecovery) est activé afin de promouvoir le prochain maître approprié.
Maintenant, mon maître actuel est en panne, donc le réplica en lecture tente à nouveau de se connecter le maître.
Erreur de réplication à partir du réplica en lecture
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)Une fois que le ClusterControl promeut le prochain maître approprié, mon réplica en lecture se connectera à l'un des nœuds de cluster disponibles.
Le processus de basculement automatique est terminé et mon réplica en lecture rejoint le nœud 1 (192.168.33.13) serveur.
Conclusion
C'est l'une des grandes fonctionnalités de MySQL, aucune intervention manuelle n'est nécessaire. Ce processus de basculement automatique peut vous faire gagner du temps. Et cela réduit la panne du serveur de réplique. À noter, lorsque mon ancien maître est revenu à la rotation, la connexion de réplication ne revenait pas à l'ancien maître.
