MySQL主主复制单表不同步如何修复？可从正常节点导入表数据吗？

你的思路完全可行——从正常服务器导出目标表再恢复到异常节点是处理这类单表数据滞后问题的常用方法，不过因为是主主复制架构，操作时要注意避免同步循环或数据冲突，下面是详细的操作步骤和注意事项：

一、前期准备 #

• 先确认异常节点的表状态：在异常节点执行以下命令，和正常节点的结果对比，明确数据差异：

  SELECT COUNT(*) FROM your_database.your_table_name;
  SHOW TABLE STATUS LIKE 'your_table_name';
  

• 暂停异常节点的SQL复制线程（防止恢复过程中被正常节点的同步操作干扰）：

  STOP SLAVE SQL_THREAD;
  

二、从正常节点导出目标表 #

在正常节点的终端执行mysqldump命令导出单表，推荐使用以下参数（针对InnoDB表，不锁表且保证数据一致性）：

mysqldump -u [你的用户名] -p [你的数据库名] [目标表名] --single-transaction --skip-lock-tables > table_dump.sql

• --single-transaction：利用InnoDB的事务特性，导出时创建一个快照，无需锁表，不影响业务写入
• --skip-lock-tables：避免锁表（MyISAM表不适用，若为MyISAM需改用--lock-tables，但要选择业务低峰期操作）

导出完成后，将table_dump.sql文件传输到异常节点的服务器上（比如用scp命令）。

三、在异常节点恢复表数据 #

1. 临时关闭异常节点的binlog写入（防止恢复操作被同步回正常节点，造成数据循环）：

   SET SQL_LOG_BIN=0;
   

2. 导入备份文件到异常节点的对应数据库：

   mysql -u [你的用户名] -p [你的数据库名] < table_dump.sql
   

3. 导入完成后，重新开启binlog：

   SET SQL_LOG_BIN=1;
   

4. 重启异常节点的SQL复制线程，恢复主主同步：

   START SLAVE SQL_THREAD;
   

四、验证与后续排查 #

• 数据一致性验证：在异常节点执行查询，和正常节点对比数据量及随机行内容，确认一致：

  SELECT COUNT(*) FROM your_database.your_table_name;
  SELECT * FROM your_database.your_table_name LIMIT 10; -- 随机抽查
  

• 复制状态验证：检查异常节点的复制是否正常运行：

  SHOW SLAVE STATUS\G;
  

  确保Slave_IO_Running和Slave_SQL_Running均为Yes，且Last_SQL_Error为空。
• 根源排查：一定要找出单表不同步的原因，比如：
  • 是否曾在正常节点执行过SET SQL_LOG_BIN=0;的写入操作？
  • 复制线程是否因主键冲突、表结构不一致等错误停止过？
  • 有没有特殊的触发器或存储逻辑导致复制跳过？
    解决根源问题才能避免再次出现同步异常。

内容的提问来源于stack exchange，提问作者sandy