1. Antecedentes
Permítanme compartir un error de las limitaciones de replicación maestro-esclavo que se encuentran en la operación y mantenimiento del proyecto: la arquitectura del proyecto es un clúster maestro + un clúster de recuperación ante desastres, y cada clúster es un modelo maestro-esclavo. La sincronización entre el clúster principal y el clúster de recuperación de desastres utiliza la replicación maestro-esclavo. De acuerdo con los requisitos comerciales, el clúster de recuperación de desastres debe ignorar la biblioteca del sistema y ciertas tablas de configuración, por lo que se activa esta restricción. Si no hemos encontrado esta restricción antes, entonces También es relativamente difícil de investigar.
2. Descripción de las restricciones
1. Se produce un error durante la sincronización maestro-esclavo.
greatsql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.xxx.xxx
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: greatsql-bin.000990
Read_Master_Log_Pos: 92274290
Relay_Log_File: greatsql-relay.002963 -----
Relay_Log_Pos: 701548899
Relay_Master_Log_File: greatsql-bin.000988
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: A.ab,B.bc
Last_Errno: 1146
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Skip_Counter: 0
Exec_Master_Log_Pos: 701548690
Relay_Log_Space: 2246320360
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 1146
Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988, end_log_pos 701570116. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1943306
Master_UUID: 9e668a93-2618-11ee-93ee-bc16954181bb
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State:
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp: 230822 14:14:18
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 9e668a93-2618-11ee-93ee-bc16954181bb:2-47565802
Executed_Gtid_Set: 30873cfe-8750-11ed-b56f-744aa4073024:1-270,
9e668a93-2618-11ee-93ee-bc16954181bb:1-47508256
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
1 row in set (0.00 sec)
Se puede ver en la información del estado del esclavo que
- El GTID informado en el error es:
'9e668a93-2618-11ee-93ee-bc16954181bb:47508257' - El binlog del cluster principal de la aplicación es:
greatsql-bin.000988 - El registro de retransmisión del clúster de recuperación ante desastres es:
greatsql-relay.002963
performance_schema.replication_applier_status_by_workerTabla de vista de información detallada
2. Verifique los detalles del error
greatsql> select * from performance_schema.replication_applier_status_by_worker\G
*************************** 1. row ***************************
CHANNEL_NAME:
WORKER_ID: 1
THREAD_ID: NULL
SERVICE_STATE: OFF
LAST_SEEN_TRANSACTION: 9e668a93-2618-11ee-93ee-bc16954181bb:47508257
LAST_ERROR_NUMBER: 1146
LAST_ERROR_MESSAGE: Worker 1 failed executing transaction
'9e668a93-2618-11ee-93ee-bc16954181bb:47508257' at master log greatdb-bin.000988,
end_log_pos 701570116; Error executing row event: 'Table 'abs_xxx.tmp_xxx_info' doesn't exist'
LAST_ERROR_TIMESTAMP: 2023-08-22 14:14:18
La información anterior muestra que, de acuerdo con performance_schema.replication_applier_status_by_workerla información detallada del error en la tabla, se puede encontrar que la abs_xxx.tmp_xxx_infotabla del clúster de recuperación ante desastres no existe, lo que genera un error de sincronización.
3. Análisis de problemas
3.1 Confirmar si la tabla de destino existe en el clúster de recuperación ante desastres
greatsql> show create table abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist
greatsql> desc abs_xxx.tmp_xxx_info;
ERROR 1146 (42S02): Table 'abs_xxx.tmp_xxx_info' doesn't exist
**Conclusión:** La tabla de destino en el clúster de recuperación ante desastres no existe
3.2 Analizar el binlog del clúster principal en función de la información de error maestro-esclavo y el error SQL
Analizar el binlog del clúster principal
SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47508257'/*!*/;
……
#230822 14:14:18 server id 1943306 end_log_pos 701570000 Table_map: `abs_xxx`.`tmp_xxx_info` mapped to number 1595
# at 701570000
#230822 14:14:18 server id 1943306 end_log_pos 701570116 Write_rows: table id 1595 flags: STMT_END_F
### INSERT INTO `abs_xxx`.`tmp_xxx_info`
### SET
### @1=2
### @2='自动化'
### @3='2300121212120000'
### @4='90000000'
### @5='1'
### @6='202001290231001'
### @7='2021-01-31 00:00:00'
# at 701570116
#230822 14:14:18 server id 1943306 end_log_pos 701570143 Xid = 800998400
COMMIT/*!*/;
# at 701570143
#230822 14:14:18 server id 1943306 end_log_pos 701570204 GTID last_committed=26491 sequence_number=26521 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
**Conclusión:** Según el mensaje de error copiado, podemos conocer el número GTID específico y el archivo binlog del clúster principal. Al analizar el binlog, podemos aprender que esta transacción es una declaración INSERT. La tabla de destino en el La declaración es consistente con la información de la tabla performance_schema.replication_applier_status_by_worker.
3.3 Encuentre si hay una declaración de creación de tabla en el binlog de la tabla de destino del clúster principal
Encuentre declaraciones de creación de tablas en el mismo registro binlog
SET TIMESTAMP=1692684495/*!*/;
CREATE DATABASE IF NOT EXISTS `abs_xxx` /*!40100 DEFAULT CHARACTER SET utf8 COLLATE utf8_bin */
/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864451
**Conclusión:** La declaración de creación de la tabla de destino se encontró en el registro binlog del clúster principal, lo que indica que el clúster principal no cerró el registro binlog al ejecutar DDL. Luego continúe verificando si hay una declaración DDL. en el registro de retransmisión del clúster de recuperación ante desastres.
3.4 Analice el registro de retransmisión del clúster de recuperación de desastres y confirme si se extrae al clúster de recuperación de desastres.
#230822 14:08:15 server id 1943306 end_log_pos 475863662 GTID last_committed=16341 sequence_number=16342 rbr_only=no
SET @@SESSION.GTID_NEXT= '9e668a93-2618-11ee-93ee-bc16954181bb:47498079'/*!*/;
……
use `information_schema`/*!*/;
SET TIMESTAMP=1692684495/*!*/;
CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC
/*!*/;
# at 475864660
#230822 14:08:15 server id 1943306 end_log_pos 475864512 GTID last_committed=16342 sequence_number=16343 rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
**Conclusión:** Hay una declaración de creación de tabla DDL en el registro de retransmisión del clúster de recuperación ante desastres, que indica que no hay ningún problema con el subproceso IO.
3.5 Verifique la tabla de biblioteca ignorada de la configuración de replicación
Replicate_Ignore_DB: mysql,dbscale,dbscale_tmp,information_schema,performance_schema,sys
Replicate_Wild_Ignore_Table: A.ab,B.bc
**Conclusión:** La tabla de destino no está incluida en la tabla de biblioteca ignorada. Sin embargo, según el registro analizado anteriormente, se encuentra que hay una declaración antes de la declaración de creación de la tabla en el registro binlog del clúster principal. Esta biblioteca use information_schema/!/; es una biblioteca del sistema que se ignora mediante la sincronización, por lo que activa las restricciones de especificación de GreatSQL. La grabación de declaraciones en el modo Declaración no funciona de forma predeterminada para operaciones que no se ignoran en la biblioteca ignorar (detalles: https://dev.mysql.com/doc /refman/5.7/es/opciones-de-replicación-replica.html#option_mysqld_replicate-do-db)
4. Resolver errores de sincronización
Cree una tabla de destino en el clúster de recuperación ante desastres
greatsql> CREATE TABLE `abs_xxx`.`tmp_xxx_info` (
`ID` int(64) NOT NULL AUTO_INCREMENT,
`CUSTOMER_NAME` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`CUSTOMER_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`PRODIST_SKU_NUM` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`STATUS` varchar(64) COLLATE utf8mb4_bin DEFAULT NULL,
`AGREEMENT_NUM` varchar(256) COLLATE utf8mb4_bin DEFAULT NULL,
`END_DATE` datetime DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `PK_PRODIST_SKU_NUM_AGREEMENT` (`PRODIST_SKU_NUM`) USING BTREE,
KEY `IDX_AGREEMENT_NUM` (`AGREEMENT_NUM`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ROW_FORMAT=DYNAMIC;
greatsql> stop slave;
greatsql> start slave;
**Conclusión:** Después de crear la tabla de destino en el clúster de recuperación ante desastres, la replicación y la recuperación fueron exitosas.
3. Evitación de restricciones
1. La primera forma de evitar
Ingrese la biblioteca de destino al ejecutar DDL
greatsql> use abs_cust
greatsql> DDL 语句（CREATE\DROP\ALTER）
**Nota:** Cuando la aplicación se conecta a la base de datos, puede utilizar information_schemala biblioteca de forma predeterminada y este entorno ignora todas las bibliotecas del sistema. Por lo tanto, para evitar problemas similares, utilice la biblioteca de destino de la tabla de destino antes de ejecutar el Declaración SQL.
2. La segunda forma de evitar
Modifique la configuración de replicación maestro-esclavo, los siguientes pasos son para el entorno de prueba
Apague el clúster de recuperación ante desastres durante la sincronización de la replicación
greatsql> stop slave;
Query OK, 0 rows affected, 1 warning (0.03 sec)
Modificar ignorar biblioteca
greatsql> change replication filter Replicate_Ignore_DB=();
Modificar ignorar tabla
greatsql> change replication filter replicate_wild_ignore_table =('mysql.%','information_schema.%','sys.%','performance_schema.%');
Iniciar sincronización
greatsql> start slave;
Query OK, 0 rows affected, 1 warning (0.37 sec)
Verificación de prueba
Grupo principal:
greatsql> use mysql
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
greatsql> create table test111.test111(id int primary key);
Query OK, 0 rows affected (0.06 sec)
greatsql> show tables;
+-------------------+
| Tables_in_test111 |
+-------------------+
| test111 |
+-------------------+
1 row in set (0.00 sec)
Clúster de recuperación ante desastres:
greatsql> use test111
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
greatsql> show tables;
+-------------------+
| Tables_in_test111 |
+-------------------+
| test111 |
+-------------------+
1 row in set (0.00 sec)
**Nota:** Si los parámetros en la configuración de copia Replicate_Ignore_DBestán vacíos, también se pueden evitar problemas similares replicate_wild_ignore_tableestableciendo los parámetros enshema_name.%
4. Instrucciones especiales
- Esta limitación también existe en las versiones MySQL 5.7 y 8.0.
Disfruta de GreatSQL :)
Acerca de GreatSQL
GreatSQL es una base de datos nacional independiente de código abierto adecuada para aplicaciones de nivel financiero. Tiene muchas características principales, como alto rendimiento, alta confiabilidad, alta facilidad de uso y alta seguridad. Puede usarse como un reemplazo opcional de MySQL o Percona Server. y se utiliza en entornos de producción online, completamente gratuito y compatible con MySQL o Percona Server.
Enlaces relacionados: Comunidad GreatSQL Gitee GitHub Bilibili
Gran comunidad SQL:
Sugerencias y comentarios sobre recompensas de la comunidad: https://greatsql.cn/thread-54-1-1.html
Detalles de la presentación del premio del blog comunitario: https://greatsql.cn/thread-100-1-1.html
(Si tiene alguna pregunta sobre el artículo o tiene ideas únicas, puede ir al sitio web oficial de la comunidad para preguntarlas o compartirlas ~)
Grupo de intercambio técnico:
Grupo WeChat y QQ:
Grupo QQ: 533341697
Grupo WeChat: agregue GreatSQL Community Assistant (ID de WeChat:) wanlidbccomo amigo y espere a que el asistente de la comunidad lo agregue al grupo.