MySQL主从备份须在从库做物理备份并记录binlog位点，主库仅作带--master-data=2的逻辑备份；需验证恢复、归档binlog、自动化监控延迟与校验。
在 MySQL 主从环境中，备份不能只盯着主库或从库单独操作，必须结合复制状态、数据一致性与恢复可用性来设计。核心原则是：备份时确保 binlog 位置与数据文件严格对应，且优先在从库执行物理备份（降低主库压力，避免锁表影响业务）。
从库上做物理备份（推荐）
从库通常负载较低，适合执行耗时的物理备份（如 Percona XtraBackup 或 mysqldump 加 --single-transaction）。关键点在于备份前需暂停复制并记录当前 relay log 和 master log 位点，保证备份可精准回放到任意时间点。
- 执行
STOP SLAVE;暂停复制 - 运行
SHOW SLAVE STATUS\G，记下 Relay_Master_Log_File 和 Exec_Master_Log_Pos（即主库已执行到的 binlog 文件和位置） - 用 XtraBackup 备份从库数据目录（自动记录
xtrabackup_binlog_info，含 binlog 名称与位置） - 备份完成后执行
START SLAVE;
主库上做逻辑备份（补充用途）
逻辑备份（mysqldump）适合小规模数据库或需要跨版本/跨引擎迁移的场景，但主库执行需谨慎。务必使用 --master-data=2 参数，让 dump 文件中自动包含 CHANGE MASTER TO 所需的 binlog 坐标。
- 加
--single-transaction减少锁表（仅对 InnoDB 有效） - 避免在高并发写入时段执行，否则可能拉长事务、拖慢主库
- dump 文件本身不含实时数据变更，仅反映执行时刻的一致快照
备份后验证与归档要点
备份不是“存完就完”，必须验证可恢复性，并规范管理 binlog 归档。
- 定期用备份+binlog 模拟一次完整恢复流程（尤其测试从指定位置启动复制）
- 主库 binlog 必须开启
expire_logs_days并配合定时归档（如 rsync 到独立存储），确保备份点之后的 binlog 不丢失 - 备份文件与对应 binlog 范围需打标签，例如：
backup_20240520_142300_slave1_full.tar.gz + binlog.000123–000135
自动化与监控建议
人工操作易出错，应通过脚本固化流程，并加入关键检查项。
- 备份脚本开头自动校验
Seconds_Behind_Master ，延迟过大则中止备份 - 备份后立即比对
md5sum并发送校验结果到运维群 - 用 Prometheus + mysqld_exporter 监控从库复制延迟、IO/SQL 线程状态，异常时触发告警
