replicate-wild-ignore-table

本文讨论了在MySQL主从备份过程中遇到的问题,即在my.cnf文件中添加binlog-do-db参数后,binlog记录停止。通过排除故障流程,作者最终采用在从库中使用replicate-wild-ignore-table参数来过滤数据库表,成功解决了问题,并验证了复制过程恢复正常。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

由于公司业务需求,需要将先前mysql数据库服务器中添加第二个数据库的主从备份,打开my.cnf文件,发现配置文件中指定了binlog-do-db参数,后面填写了一个数据库名,按照常规,如果想再添加一个需要记录binlog的数据库名就可以了,因此我修改如下:
binlog-do-db = dbname1,dbname2
修改后重启mysql,发现binlog不再记录日志了,从库复制进程都正常,mysql也没有报任何错误。接下来开始排除问题:
(1)查看主从mysql的错误日志,看是否有错误输出
(2)在主库中使用show master status和在从库中使用show slave status\G命令查看从库复制情况。
(3)查看配置文件看配置选项是否有不妥之处
(4)修改主从配置文件,重启mysql再试

经过上面1-3步的分析,没有发现任何的错误,随即g.cn了一把,发现了MySQL Performance Blog的一篇文章,文章中建议不要使用binlog-do-db、binlog-ignore-db、replicate-do-db 和 replicate-ignore-db的参数,而是建议在从库中使用replicate-wild-ignore-table=dbname.%的参数对数据库表的过滤。详细的说明可以参考这篇文章:Why MySQL's binlog-do-db option is dangerous 同样的,要过滤多个数据库的表,中间用逗号隔开。但进过测试发现,如果主库中有dbname1数据库而从库没有这个数据库的话,从库复制会发生错误。最后我打算使用binlog-ignore-db参数再试一下,修改配置文件后,重启mysql,在从库中将主库没有的数据库在从库重新导入,主库中查看状态如下:

root@db001  [ (none ) ]  >show master  STATUS;
+ ------------------+----------+--------------+--------------------------+
| File              | Position  | Binlog_Do_DB  | Binlog_Ignore_DB          |
+ ------------------+----------+--------------+--------------------------+
| mysql -bin .007087  |    193424  |               | information_schema ,mysql  |
+ ------------------+----------+--------------+--------------------------+

从库状态如下:

root@db002  [ (none ) ]  >show slave  STATUS\G
***************************  1 . row  ***************************
Slave_IO_State: Waiting  FOR master  TO send event
Master_Host: 192 .168 .99 .61
Master_User: repl
Master_Port:  3306
Connect_Retry:  60
Master_Log_File: mysql -bin .007087
Read_Master_Log_Pos:  165652
Relay_Log_File: mysql -relay -bin .000002
Relay_Log_Pos:  151428
Relay_Master_Log_File: mysql -bin .007087
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table: dbname1 .% ,dbname2 .%
Last_Errno:  0
Last_Error:
Skip_Counter:  0
Exec_Master_Log_Pos:  165652
Relay_Log_Space:  151583
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:  0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno:  2013
Last_IO_Error:
Last_SQL_Errno:  0
Last_SQL_Error:
1 row  IN  SET  ( 0.00 sec )

那些忽略的数据库我是不关心的,经过测试,我想要同步的数据可以同步到从库了,现在来看,复制是正常的,等待继续观察……

从库中虽然使用了Replicate_Wild_Ignore_Table参数设置了需要过滤的表,但在实际测试中并没有骑到过滤的作用,这一部分需要进一步的测试……

mysql> SHOW SLAVE STATUS\G; *************************** 1. row *************************** Slave_IO_State: Master_Host: Master_User: Master_Port: 3306 Connect_Retry: 60 Master_Log_File: Read_Master_Log_Pos: 4 Relay_Log_File: mysql-binlog.000001 Relay_Log_Pos: 1821 Relay_Master_Log_File: Slave_IO_Running: No Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1049 Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '28d37105-660a-11f0-bb16-8ac03ce6f98d:2' at master log , end_log_pos 2104, consensus_index 1. 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: 1821 Relay_Log_Space: 3506 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: 1049 Last_SQL_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction '28d37105-660a-11f0-bb16-8ac03ce6f98d:2' at master log , end_log_pos 2104, consensus_index 1. 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: 0 Master_UUID: 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: 250721 19:27:29 Master_SSL_Crl: Master_SSL_Crlpath: Retrieved_Gtid_Set: 03f40bd3-6608-11f0-9943-16f83da9284e:1-3, 28d37105-660a-11f0-bb16-8ac03ce6f98d:1-7 Executed_Gtid_Set: 28d37105-660a-11f0-bb16-8ac03ce6f98d:1 Auto_Position: 0 Replicate_Rewrite_DB: Channel_Name: Master_TLS_Version: Master_public_key_path: Get_master_public_key: 0 Network_Namespace: 1 row in set, 1 warning (0.00 sec) ERROR: No query specified mysql>
最新发布
07-22
<think>首先,用户的问题是关于MySQL复制错误:"Coordinator stopped because there were error(s) in the worker(s)",具体错误是Last_SQL_Error: 1049。用户引用了之前的错误示例,但这次是1049错误。 用户查询的关键点: - 错误信息:Coordinator stopped because there were error(s) in the worker(s) - 具体错误:Worker failed executing transaction, Last_SQL_Error: 1049 - 参考引用中提到了1032和1062错误,但用户这次指定了1049错误。 我需要理解错误1049的含义: -MySQL中,错误1049对应于"ER_BAD_DB_ERROR",意思是"Unknown database",即未知数据库错误。这通常发生在从服务器尝试访问一个在主服务器上存在但在从服务器上不存在的数据库时。 用户场景: - 用户正在查看MySQL从服务器的状态,遇到了复制错误。 - 用户想要了解这个错误的原因以及如何解决它。 根据系统级指令: - 所有行内数学表达式必须使用$...$格式。 - 独立公式必须使用$$...$$格式并单独成段。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识,例如[^1]。 - 回答结构清晰,帮助用户逐步解决问题。 用户引用的内容: - 引用[1]和[2]是关于复制错误的示例,但用户指定了1049错误。我需要基于这个错误提供解决方案。 我的回答结构: 1. **解释错误原因**:用简单中文解释1049错误是什么,为什么发生。 2. **提供解决步骤**:逐步指导用户如何解决这个问题。 3. **生成相关问题**:基于主题,生成几个相关问题。 4. **引用处理**:在适当的地方添加引用标识。由于用户提供了引用,我可以引用它们来支持解释,但主要针对1049错误。 可能的解决方案: - 错误1049:Unknown database。解决方法: - 检查从服务器上是否缺少数据库- 确保从服务器有与主服务器相同的数据库- 如果数据库不需要,可以跳过错误或创建数据库- 使用SQL_SLAVE_SKIP_COUNTER或GTID跳过错误。 参考用户提供的引用: - 引用[1]和[2]是关于其他错误(1032和1062),但机制类似:复制错误时,协调器停止。 - 我可以引用这些来一般性地解释复制错误处理,但焦点是1049。 回答大纲: - 开头:确认错误并解释。 - 步骤: 1. 检查错误详情。 2. 验证数据库是否存在。 3. 创建缺失的数据库。 4. 跳过错误或重新启动复制。 - 结尾:预防措施。 - 相关问题。 确保语言:中文。 生成相关问题: - 根据指令:"生成相关问题",在回答末尾添加§§相关问题§§部分。 - 问题应相关:如如何预防复制错误、其他常见复制错误等。 最终输出格式: - 回答内容。 - §§相关问题§§ - 相关问题列表。</think>### MySQL复制错误1049的解析与解决 当MySQL从服务器在执行复制过程中遇到错误时,会报告类似"Coordinator stopped because there were error(s) in the worker(s)"的消息。具体到您的案例,`Last_SQL_Error: 1049`表示一个**未知数据库错误**(Unknown database)。这通常发生在从服务器尝试应用主服务器的二进制日志(binlog)时,但目标数据库在从服务器上不存在或名称不匹配。例如,主服务器执行了`USE non_existent_db;`或`CREATE TABLE non_existent_db.table ...`命令,而从服务器上缺少该数据库[^1]。下面我将逐步解释原因并提供解决方案,确保复制恢复正常。 #### 错误原因分析 - **错误1049的本质**:在MySQL中,错误1049对应`ER_BAD_DB_ERROR`,表示从服务器无法找到主服务器指定的数据库。常见原因包括: - 主服务器上创建或使用了新数据库,但从服务器未同步创建。 - 数据库名称大小写不一致(尤其在Linux系统上,MySQL默认区分大小写)。 - 复制过滤规则(如`replicate-ignore-db`)配置不当,导致部分数据库被忽略[^2]。 - **复制机制背景**:MySQL复制基于主从架构,主服务器记录操作到binlog,从服务器通过I/O线程读取并应用这些日志。如果应用过程中遇到错误(如1049),协调器(Coordinator)会停止工作线程(Worker),并报告详细错误[^1][^2]。 #### 解决步骤(逐步操作指南) 请按照以下步骤操作,确保从服务器与主服务器数据一致。操作前,**备份从服务器的数据**,以防意外。 1. **确认错误详情**: - 登录从服务器的MySQL命令行。 - 执行`SHOW REPLICA STATUS\G`(MySQL 8.0+)或`SHOW SLAVE STATUS\G`(旧版本)。 - 检查输出中的`Last_Error`字段,确认错误为1049,并记录相关事务ID和binlog位置。例如: ``` Last_Errno: 1049 Last_Error: Coordinator stopped because there were error(s) in the worker(s)... Worker 1 failed executing transaction '...' at source log binlog.00000X, end_log_pos YYYYY ``` 这将帮助定位具体出错的事务[^2]。 2. **验证数据库是否存在**: - 在从服务器上,运行`SHOW DATABASES;`,检查主服务器报错的数据库是否在列表中。 - 如果缺失,需手动创建该数据库: ```sql CREATE DATABASE IF NOT EXISTS your_database_name; ``` 替换`your_database_name`为错误中提到的数据库名。确保名称大小写与主服务器完全一致[^1]。 3. **跳过错误或恢复复制**: - **方法1:自动修复(推荐)**:如果数据库已创建,重启复制即可: ```sql STOP REPLICA; -- 或 STOP SLAVE 在旧版本中 START REPLICA; -- 或 START SLAVE ``` 复制会从上次中断的位置继续。 - **方法2:手动跳过错误**:如果数据库不需要(如测试库),可以跳过该事务: - **使用GTID(如果启用)**: ```sql STOP REPLICA; SET GTID_NEXT='transaction_id'; -- 替换为错误中的事务ID,如 'be41e172-f145-11ec-9b3c-00155d5aa636:247' BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START REPLICA; ``` - **使用binlog位置(非GTID)**: ```sql STOP REPLICA; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; -- 跳过1个事务 START REPLICA; ``` 此方法需谨慎,仅用于无关紧要的事务,以避免数据不一致[^2]。 4. **检查复制状态**: - 执行`SHOW REPLICA STATUS\G`,确认`Replica_IO_Running`和`Replica_SQL_Running`均为`Yes`,且`Last_Errno`为0。 - 如果错误依旧,查看MySQL错误日志(默认位置`/var/log/mysql/error.log`),获取更多上下文。 #### 预防措施 - **同步数据库结构**:在修改主服务器数据库前,先在从服务器执行相同操作。 - **配置复制过滤**:在`my.cnf`文件中使用`replicate-ignore-db`或`replicate-wild-ignore-table`忽略非关键数据库,减少错误风险。 - **监控工具**:使用`performance_schema.replication_applier_status_by_worker`表实时监控工作线程状态[^1][^2]。 通过以上步骤,1049错误通常能快速解决。如果问题复杂或涉及数据损坏,建议使用`mysqldump`重新初始化从服务器。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值