先定位问题类型再选择恢复方式。检查主从状态，根据错误类型选择跳过事务、GTID恢复或重建从库，推荐重建确保一致性，同时设置read_only、开启GTID并监控复制状态预防问题。
MySQL从库数据恢复通常是因为主从同步中断、数据不一致或误操作导致。恢复的核心是确保从库能重新与主库保持一致，同时不影响业务。以下是几种常见场景下的恢复方法。
1. 检查主从状态和错误原因
先确认当前从库的复制状态：
SHOW SLAVE STATUS\G
重点关注以下字段：
- Slave_IO_Running：是否正常拉取主库binlog
- Slave_SQL_Running：是否正常执行SQL
- Last_Error：最近的错误信息
- Seconds_Behind_Master：延迟时间
根据错误信息判断是网络问题、权限问题、数据冲突还是SQL执行失败。
2. 常见恢复方式
根据实际情况选择合适的恢复策略：
（1）跳过单个错误事务适用于主库执行了DROP TABLE等从库不能接受的操作，或唯一键冲突等可忽略错误：
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;
注意：sql_slave_skip_counter只能跳过一个event，且在基于语句复制模式下使用更谨慎。
（2）基于GTID跳过事务如果启用了GTID（gtid_mode=ON），可以跳过指定事务：
STOP SLAVE; SET GTID_NEXT='caa9a1ea-cccc-eeee-aaaa-000000000001:12345'; BEGIN; COMMIT; SET GTID_NEXT='AUTOMATIC'; START SLAVE;
其中GTID值来自Last_Error中的信息。
（3）重新搭建从库（推荐用于严重不一致）当数据差异大或无法修复时，最稳妥的方式是重建从库：
- 在主库执行
mysqldump导出全量数据 - 记录主库当前binlog位置：
SHOW MASTER STATUS; - 将dump文件导入从库
- 配置从库指向该binlog位置并启动复制
示例命令：
mysqldump -u root -p --all-databases --master-data=2 --single-transaction > backup.sql
导入后执行：
CHANGE MASTER TO MASTER_HOST='主库IP', MASTER_USER='repl', MASTER_PASSWORD='密码', MASTER_LOG_FILE='binlog.000001', MASTER_LOG_POS=1234; START SLAVE;
3. 预防措施
避免频繁出现从库问题，建议：
- 从库设置
read_only=ON防止误写 - 定期检查主从延迟和一致性（可用pt-table-checksum）
- 开启GTID，便于故障转移和恢复
- 监控复制线程状态
基本上就这些。关键是先定位问题类型，再选择跳过错误还是重建同步。对于生产环境，重建从库虽然耗时但更安全可靠。
