17370845950

修复MySQL从库数据一致性需先定位问题，再停用旧复制、基于主库一致快照重建：通过SHOW SLAVE STATUS等命令诊断不一致原因，用pt-table-checksum校验，STOP SLAVE后RESET SLAVE ALL清空状态，最后FLUSH TABLES WITH READ LOCK获取binlog位置并mysqldump导出导入。

重新同步 MySQL 从库以修复数据一致性，核心是停止复制、重置从库状态、重建主从关系。关键不在于“快”，而在于“准”——确保主库当前状态被完整、无误地复制到从库。

确认主从不一致的具体位置

先别急着重做，定位问题是前提：

• 用 SHOW SLAVE STATUS\G 查看 Seconds_Behind_Master、SQL_Delay、Slave_SQL_Running_State，判断是延迟、中断还是已错位
• 对比主从的 SHOW MASTER STATUS（主）和 SHOW SLAVE STATUS 中的 Master_Log_File 与 Read_Master_Log_Pos，看是否指向同一 binlog 位置
• 若怀疑数据行不一致，可用 pt-table-checksum（Percona Toolkit）在主库运行校验，再用 pt-table-sync 生成修复语句（慎用于生产）

停用并清理旧复制通道

安全起见，先彻底停止并清除当前可能出错的复制链路：

• 在从库执行：STOP SLAVE;
• 清空中继日志：RESET SLAVE ALL;（MySQL 5.7+ 推荐，会清除 master.info、relay-log.info 等所有复制元数据）
• 删除残留 relay log 文件（可选，RESET SLAVE ALL 已自动处理，但可手动检查 ls -l /var/lib/mysql/relay* 确认）

基于一致快照重建从库

最可靠的方式是从主库导出一个带 binlog 位置的逻辑快照，再导入从库：

• 在主库加全局读锁（短时间）：FLUSH TABLES WITH READ LOCK;
• 立即记录当前 binlog 位置：SHOW MASTER STATUS; 记下 File 和 Position
• 用 mysqldump 导出（含 --master-data=2 自动写入 CHANGE MASTER 语句）：
  mysqldump --all-databases --single-transaction --master-data=2 -u root -p > full_dump.sql
• 解锁：UNLOCK TABLES;
• 将 full_dump.sql 传至从库，清空原数据（如非全新实例，先 DROP DATABASE 或重装 datadir），再导入：
  mysql -u root -p

配置并启动新复制

导入完成后，用之前记下的 binlog 位置启动复制：

• 在从库执行：
  

  CHANGE MASTER TO
  
    MASTER_HOST='主库IP',
  
    MASTER_USER='repl',
  
    MASTER_PASSWORD='xxx',
  
    MASTER_PORT=3306,
  
    MASTER_LOG_FILE='mysql-bin.000001',
  
    MASTER_LOG_POS=12345;

• 启动复制：START SLAVE;
• 验证：SHOW SLAVE STATUS\G 中 Slave_IO_Running 和 Slave_SQL_Running 均为 Yes，且 Seconds_Behind_Master 逐步归零

不复杂但容易忽略：整个过程需确保主库 binlog 格式为 ROW（binlog_format=ROW），否则某些 DML 操作无法被准确重放；另外，从库 server_id 必须与主库及其他从库不同，且不能为 0。