MySQL主从复制不提供快照功能，需用mysqldump --single-transaction --master-data=2在从库生成带binlog位点的每日一致性备份，并配合延迟检测、命名规范、保留策略及完整链路验证。
MySQL主从复制本身不提供快照功能，得靠外部机制
主从复制只是实时同步 binlog，从库数据随时在变，直接 tar 或 mysqldump 会遇到一致性问题。想“每日自动定时快照”，本质是：在从库上定期生成某一时点的、可恢复的、隔离的数据副本——这必须绕开复制链路，用备份工具配合复制位点控制。
- 不能直接
mysqldump后 tar 整个/var/lib/mysql：InnoDB 文件不可直接拷贝（除非已停写且innodb_fast_shutdown=0） - 不能只依赖
SHOW SLAVE STATUS的Exec_Master_Log_Pos就认为“此刻可以安全 dump”：dump 过程中主库仍在写入，从库可能追平或延迟变化 - 推荐用
mysqldump --single-transaction --master-data=2：它会在事务开始时记录 binlog 位置，并保证导出期间看到一致快照（仅对 InnoDB 有效）
如何让每日快照带可回溯的复制位点信息
没有位点标记的快照等于没备份——你无法知道这个 dump 对应主库哪个时刻的状态，也就没法做基于时间点的恢复或重建新从库。
-
mysqldump --master-data=2会在 dump 文件开头插入类似CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=154;的注释，这就是关键位点 - 如果用
mydumper，需加--snapshot-method=lockless+--binlog参数才能获取位点；mydumper默认不输出位点 - 注意：
--master-data=1会把CHANGE MASTER语句作为 SQL 执行，=2是注释形式，更安全，避免误执行
crontab 定时 + 脚本封装的关键细节
单纯写个 0 2 * * * mysqldump ... > /backup/$(date +\%F).sql 很容易失败或堆积垃圾文件。
- 务必用完整路径调用命令：
/usr/bin/mysqldump而不是mysqldump，crontab 环境变量极简，PATH 通常不含/usr/local/mysql/bin - 每次备份前检查从库是否延迟：
mysql -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master:" | awk '{print $2}'，大于 60 秒建议跳过本次快照（否则备份的是严重滞后的状态） - 保留最近 7 天快照，用
find /backup -name "*.sql" -mtime +7 -delete，别用rm -f /backup/*.sql——后者会清空所有，包括正在写的临时文件 - 备份文件名必须含日期和位点标识，例如：
backup_2024-04-05_0200_bin.000012_154.sql，方便人工快速识别
从库快照 ≠ 主库高可用保障，别混淆用途
这种快照是离线恢复用的，不是热切换方案。一旦主库宕机，你不能靠“昨天的快照+今天的 binlog”立刻顶上——中间差了 24 小时数据，且补 log 极易出错。
- 快照只能用于：重建从库、审计历史状态、满足合规留存要求
- 真正应对主库故障，必须依赖半同步复制 +
orchestrator或MHA这类故障转移工具，而不是等 cron 跑完 dump - 如果业务允许分钟级 RPO，建议同时开启
binlog归档（如用mysqlbinlog --read-from-remote-server拉取并压缩存到对象存储），快照 + 归档 binlog 才构成完整备份链
位点对不上、脚本没权限、crontab PATH 错、从库延迟未检测——这些地方一漏，快照就成“假备份”。真要落地，先拿测试实例跑通三轮全周期（生成→校验→恢复→比对位点），再上生产。
