A Oracle lançou recentemente o MySQL 8.0.22, e esta nova versão veio com um novo mecanismo de failover de conexão assíncrona. Ele permite que uma réplica estabeleça automaticamente uma conexão de replicação assíncrona com uma nova fonte, caso a existente falhe.
Neste blog, veremos esse mecanismo de failover de conexão.
Visão geral
O mecanismo de failover assíncrono pode ser usado para manter uma réplica sincronizada com um grupo de servidores que compartilham dados (escravo de várias origens). Ele moverá a conexão de replicação para uma nova origem quando a conexão de origem existente falhar.
Princípio de funcionamento
Quando a fonte de conexão existente falha, a réplica primeiro tenta novamente a mesma conexão pelo número de vezes especificado pelo MASTER_RETRY_COUNT. O intervalo entre as tentativas é definido pela opção MASTER_CONNECT_RETRY. Quando essas tentativas são esgotadas, o mecanismo de failover de conexão assíncrona assume o processo de failover.
Observe que, por padrão, MASTER_RETRY_COUNT é 86400 (1 dia --> 24 horas) e o valor padrão MASTER_CONNECT_RETRY é 60.
Para garantir que o mecanismo de failover de conexão assíncrona possa ser ativado prontamente, defina MASTER_RETRY_COUNT para um número mínimo que permita apenas algumas tentativas de repetição com a mesma fonte, caso a falha de conexão seja causada por uma rede transitória interrupção.
Como ativar o failover de conexão assíncrona
- Para ativar o failover de conexão assíncrona para um canal de replicação, defina SOURCE_CONNECTION_AUTO_FAILOVER=1 na instrução CHANGE MASTER TO para o canal.
- Temos duas novas funções, que ajudarão a adicionar e excluir as entradas do servidor da lista de fontes.
- asynchronous_connection_failover_add_source (adicione as entradas do servidor da lista de fontes)
- asynchronous_connection_failover_delete_source (exclua as entradas do servidor da lista de fontes)
Ao usar essas funções, você precisa especificar os argumentos como ('channel','host',port,'network_namespace',weight).
Exemplo
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)Os servidores de origem precisam ser configurados na tabela "mysql.replication_asynchronous_connection_failover". Também podemos usar a tabela "performance_schema.replication_asynchronous_connection_failover" para visualizar os servidores disponíveis na lista de origem.
Observação:se você não estiver usando nenhuma replicação baseada em canal, esse mecanismo de failover funcionará. Ao executar a instrução change master, não há necessidade de mencionar nenhum nome de canal. Mas certifique-se de que o GTID esteja ativado em todos os servidores.
Casos de uso de produção
Digamos que você tenha três nós PXC-5.7 com dados de produção, rodando atrás do ProxySQL. Agora, vamos configurar a replicação assíncrona baseada em canal no nó 1 (192.168.33.12).
- nó 1 - 192.168.33.12
- nó 2 - 192.168.33.13
- nó 3 - 192.168.33.14
- Réplica de leitura - 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)Diagrama de Arquitetura
Caso de teste 1
Vamos adicionar as configurações de 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 tudo bem, posso ativar o auto_failover. Vamos parar o nó 1 (192.168.33.12) MySQL. O ProxySQL promoverá o próximo mestre adequado.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceNo servidor de réplica
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)O thread de E/S está no estado "conectando". Isso significa que ele está tentando estabelecer a conexão da fonte existente (nó 1) com base nas configurações master_retry_count e master_connect_retry .
Após alguns segundos, você pode ver que source_host foi alterado para o nó 2 (192.168.33.13). Agora o failover está feito.
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:Do registro de erros
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 de teste 2
Ao executar a instrução change master, não há necessidade de mencionar nenhum nome de canal, esteja você usando a replicação baseada em canal ou não.
Exemplo
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)Em seguida, adicione as configurações de failover como abaixo,
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)Agora, vou parar o nó 1 (192.168.33.12).
Erro de replicação
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)No registro de erros
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.Usando ClusterControl
Agora, usaremos o ClusterControl para repetir esse processo de failover automático. Tenho três nós pxc (5.7) implantados pelo ClusterControl. Eu tenho um escravo de replicação 8.0.22 no meu node2 PXC e vamos adicionar esta réplica de leitura usando o ClusterControl.
Etapa 1
Configure o logon SSH sem senha do nó ClusterControl para ler o nó de réplica.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Etapa 2
Vá para ClusterControl e clique no ícone suspenso e selecione a opção Add Replication slave.
Etapa 3
Em seguida, escolha a opção “Existing Replication Slave” e digite o IP da réplica de leitura e clique em “Add Replication Slave”.
Etapa 4
Um trabalho será acionado e você poderá monitorar o progresso em ClusterControl> Logs> Trabalhos. Quando o processo estiver concluído, o escravo aparecerá na sua página Visão geral, conforme destacado na captura de tela a seguir.
Agora você pode verificar a topologia atual em ClusterControl> Topology
Processo de failover automático de réplica
Agora vou fazer o teste de failover e adicionar as configurações abaixo a esta função (asynchronous_connection_failover_add_source) na minha réplica de leitura.
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)
Vou parar o nó 2 (192.168.33.13). No ClusterControl, o parâmetro (enable_cluster_autorecovery) é habilitado para promover o próximo mestre adequado.
Agora meu mestre atual está inativo, então a réplica de leitura está tentando se conectar novamente O mestre.
Erro de replicação da réplica de leitura
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)Uma vez que o ClusterControl promova o próximo mestre adequado, minha réplica de leitura se conectará a qualquer um dos nós de cluster disponíveis.
O processo de failover automático foi concluído e minha réplica de leitura voltou ao nó 1 (192.168.33.13) servidor.
Conclusão
Este é um dos grandes recursos do MySQL, não há necessidade de intervenção manual. Esse processo de failover automático pode economizar algum tempo. E reduz a interrupção do servidor de réplica. Vale a pena notar que, quando meu antigo mestre voltou à rotação, a conexão de replicação não voltou para o antigo mestre.
