修复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。
