主从复制不是备份，无法恢复误删数据；真正可用的是binlog+定期全量备份；延迟复制需提前配置SOURCE_DELAY，且须验证复制一致性。
主从复制不是备份，不能直接用于恢复误删数据
MySQL 主从复制是实时同步机制，不是快照备份。一旦主库执行了 DROP TABLE 或 DELETE FROM t WHERE ...，从库几秒内也会同步执行——这意味着从库和主库一样丢失数据。靠它“恢复”，相当于从火场里抢救一张正在燃烧的复印件。
真正能支撑恢复的，是二进制日志（binlog）+ 定期全量备份（如 mysqldump 或 mysqlpump 或物理备份工具）。主从架构只是让 binlog 的消费有了冗余通道，便于做延迟从库或闪回分析，但不改变其非备份的本质。
想用从库“救数据”，必须提前配置延迟复制
只有启用 CHANGE REPLICATION SOURCE TO SOURCE_DELAY = N（MySQL 8.0.22+）或旧版 CHANGE MASTER TO MASTER_DELAY = N，才能让从库滞后主库 N 秒。这样在发现误操作后，可立即停止从库复制线程，然后从该从库导出尚未同步的数据。
- 延迟值
N需权衡：设太小（如 30 秒）可能来不及响应；设太大（如 24 小时）占用更多磁盘且relay log清理策略需同步调整 - 必须确认从库的
relay_log_recovery = ON，否则崩溃重启后可能跳过部分中继日志 - 延迟复制下，
SHOW REPLICA STATUS中的SQL_Delay和SQL_Remaining_Delay才有实际意义；仅看Seconds_Behind_Master会误导
恢复误删表/库的最小可行路径
假设你有每日凌晨 2 点的 mysqldump --single-transaction --routines --triggers 全备，以及开启 binlog_format = ROW 的主库 binlog。恢复流程不是“停主库、启从库”，而是：
- 立即在主库上执行
FLUSH LOGS，切割当前 binlog，防止后续写入污染恢复点 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | grep -A 5 -B 5 "DROP TABLE `mydb`.`user`"定位误操作的end_log_pos - 用
mysqlbinlog --stop-position=XXXX mysql-bin.000012 | mysql -u root -p mydb回放到误操作前一刻 - 若无精确 position，就用最近一次全备 + 所有 binlog（按顺序）重放，直到误操作前一个 event
mysqlbinlog --start-datetime="2024-04-05 01:59:00" \
--stop-datetime="2024-04-05 02:05:00" \
mysql-bin.000011 mysql-bin.000012 | mysql -u root -p
从库本身不可信，除非你验证过复制一致性
主从延迟、网络丢包、字符集不一致、sql_mode 差异、自增键冲突、未捕获的 INSERT ... ON DUPLICATE KEY UPDATE 行为差异，都可能导致从库数据静默偏离主库。不要默认“从库数据是对的”。
必须定期运行 pt-table-checksum（Percona Toolkit）或 MySQL 8.0+ 的 SELECT ... CHECKSUM TABLE 对比校验，且校验要在业务低峰期进行，避免锁表影响。
尤其注意：replica_parallel_workers > 0 时，pt-table-checksum 必须加 --replicate-check-only 参数，否则校验结果不可靠。
