修复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生成修复语句（慎用于生产）
停用并清理旧复制通道
安全起见，先彻底停止并清除当前可能出错的复制链路：
Word 文档生成与编辑
下载
需要创建、读取、编辑或处理 Word 文档（.docx / .dotx）时使用。触发词：'Word'、'word 文档'、'.docx'、'生成报告'、'制作合同/简历/方案/说明书'、'提取 word 内容'、'在文档里查找替换'、'给文档加页眉页脚/目录/表格'。也用于把任意内容排版成一份正式的 Word 文件。不要用它处理 PDF、Excel 或无关编程任务。中文创作场景尤其适合：小说大纲稿、投稿文档、合同、简历、工作总结。
- 在从库执行：
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<br> MASTER_HOST='主库IP',<br> MASTER_USER='repl',<br> MASTER_PASSWORD='xxx',<br> MASTER_PORT=3306,<br> MASTER_LOG_FILE='mysql-bin.000001',<br> 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。
