Oracle lanzó recientemente MySQL 8.0.22, y esta nueva versión viene con un nuevo mecanismo de conmutación por error de conexión asincrónica. Permite que una réplica establezca automáticamente una conexión de replicación asincrónica a una nueva fuente, en caso de que falle la existente.
En este blog, veremos este mecanismo de conmutación por error de conexión.
Resumen
El mecanismo de conmutación por error asíncrono se puede utilizar para mantener una réplica sincronizada con un grupo de servidores que comparten datos (esclavo multifuente). Moverá la conexión de replicación a una nueva fuente cuando falle la conexión de fuente existente.
Principio de funcionamiento
Cuando falla la fuente de conexión existente, la réplica primero vuelve a intentar la misma conexión la cantidad de veces especificada por MASTER_RETRY_COUNT. El intervalo entre intentos lo establece la opción MASTER_CONNECT_RETRY. Cuando se agotan estos intentos, el mecanismo de conmutación por error de la conexión asincrónica se hace cargo del proceso de conmutación por error.
Tenga en cuenta que, de forma predeterminada, MASTER_RETRY_COUNT es 86400 (1 día --> 24 horas) y el valor predeterminado de MASTER_CONNECT_RETRY es 60.
Para garantizar que el mecanismo de conmutación por error de la conexión asíncrona se pueda activar rápidamente, establezca MASTER_RETRY_COUNT en un número mínimo que solo permita algunos reintentos con la misma fuente, en caso de que la falla de la conexión sea causada por una red transitoria interrupción.
Cómo activar la conmutación por error de conexión asíncrona
- Para activar la conmutación por error de conexión asíncrona para un canal de replicación, configure SOURCE_CONNECTION_AUTO_FAILOVER=1 en la instrucción CHANGE MASTER TO para el canal.
- Tenemos dos funciones nuevas, que ayudarán a agregar y eliminar las entradas del servidor de la lista de fuentes.
- asynchronous_connection_failover_add_source (agregue las entradas del servidor de la lista de fuentes)
- asynchronous_connection_failover_delete_source (eliminar las entradas del servidor de la lista de fuentes)
Al usar estas funciones, debe especificar argumentos como ('canal', 'host', puerto, 'network_namespace', peso).
Ejemplo
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)Los servidores de origen deben configurarse en la tabla "mysql.replication_asynchronous_connection_failover". También podemos usar la tabla "performance_schema.replication_asynchronous_connection_failover" para ver los servidores disponibles en la lista de fuentes.
Nota:si no está utilizando ninguna replicación basada en canales, este mecanismo de conmutación por error funcionará. Mientras se ejecuta la instrucción maestra de cambio, no es necesario mencionar ningún nombre de canal. Pero asegúrese de que GTID esté habilitado en todos los servidores.
Casos de uso de producción
Supongamos que tiene tres nodos PXC-5.7 con datos de producción, ejecutándose detrás de ProxySQL. Ahora, vamos a configurar la replicación asincrónica basada en canales en el nodo 1 (192.168.33.12).
- nodo 1 - 192.168.33.12
- nodo 2 - 192.168.33.13
- nodo 3 - 192.168.33.14
- Réplica de lectura: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 arquitectura
Caso de prueba 1
Agregaremos la configuración de conmutación por error:
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 todo bien, puedo activar el auto_failover. Detengamos el nodo 1 (192.168.33.12) MySQL. ProxySQL promoverá el siguiente maestro adecuado.
[[email protected] lib]# service mysqld stop
Redirecting to /bin/systemctl stop mysqld.serviceEn el Servidor 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)El subproceso IO está en estado de "conexión". Esto significa que está intentando establecer la conexión desde la fuente existente (nodo 1) en función de la configuración master_retry_count y master_connect_retry .
Después de unos segundos, puede ver que source_host se cambió al nodo 2 (192.168.33.13). Ahora la conmutación por error está hecha.
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:Desde el registro de errores
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 prueba 2
Mientras se ejecuta la declaración maestra de cambios, no es necesario mencionar ningún nombre de canal, ya sea que esté utilizando la replicación basada en canales o no.
Ejemplo
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)Luego agregue la configuración de conmutación por error como se muestra a continuación,
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)Ahora, voy a detener el nodo 1 (192.168.33.12).
Error de replicación
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)Desde el registro de errores
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.Uso de ClusterControl
Ahora usaremos ClusterControl para repetir este proceso de conmutación por error automático. Tengo tres nodos pxc (5.7) implementados por ClusterControl. Tengo un esclavo de replicación 8.0.22 en mi PXC node2 y agregaremos esta réplica de lectura usando ClusterControl.
Paso 1
Configure el inicio de sesión SSH sin contraseña desde el nodo ClusterControl para leer el nodo de réplica.
$ ssh-copy-id -i ~/.ssh/id_rsa 192.168.33.15Paso 2
Vaya a ClusterControl y haga clic en el ícono desplegable y seleccione la opción Agregar esclavo de replicación.
Paso 3
Luego, elija la opción "Esclavo de replicación existente" e ingrese la IP de la réplica de lectura y luego haga clic en "Agregar esclavo de replicación".
Paso 4
Se activará un trabajo y podrá monitorear el progreso en ClusterControl> Registros> Trabajos. Una vez que se complete el proceso, el esclavo aparecerá en su página de Descripción general como se destaca en la siguiente captura de pantalla.
Ahora puede comprobar la topología actual en ClusterControl> Topología
Proceso de conmutación por error automático de réplica
Ahora voy a realizar una prueba de conmutación por error y agregaré la siguiente configuración a esta función (asynchronous_connection_failover_add_source) en mi réplica de lectura.
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)
Voy a detener el nodo 2 (192.168.33.13). En ClusterControl, el parámetro (enable_cluster_autorecovery) está habilitado, por lo que promoverá el siguiente maestro adecuado.
Ahora mi maestro actual está inactivo, por lo que la réplica de lectura está intentando conectarse de nuevo el maestro.
Error de replicación de la réplica de lectura
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 vez que ClusterControl promueve el siguiente maestro adecuado, mi réplica de lectura se conectará a cualquiera de los nodos de clúster disponibles.
El proceso de conmutación por error automático se completó y mi réplica de lectura se unió nuevamente al nodo 1 (192.168.33.13) servidor.
Conclusión
Esta es una de las grandes características de MySQL, no se necesita intervención manual. Este proceso de conmutación por error automático puede ahorrarle algo de tiempo. Y reduce la interrupción del servidor de réplica. Vale la pena señalar que, cuando mi maestro anterior volvió a la rotación, la conexión de replicación no volvería a cambiar al maestro anterior.
