必须关闭主库写入同步，因为从库备份时若未执行STOP SLAVE，会导致Seconds_Behind_Master突增、binlog堆积、心跳超时；需配合--single-transaction、--slave-info等参数并校验复制位点一致性。
在从库上执行备份：为什么必须关掉主库写入同步？
从库备份本身不直接影响主库，但很多人误以为“只要连的是从库，备份就绝对安全”。真实情况是：mysqldump 或 Percona XtraBackup 在从库执行时，若未暂停复制，可能触发 Seconds_Behind_Master 突增，间接导致主库 binlog 堆积、网络压力上升，甚至触发主从心跳超时。
- 备份期间务必先执行
STOP SLAVE;，避免 IO 线程持续拉取 binlog、SQL 线程并发执行造成锁竞争 - 若使用
--single-transaction，需确认从库已开启read_committed隔离级别，否则可能因长事务阻塞其他查询 - 不要依赖
START SLAVE UNTIL自动恢复——备份完成后再手动START SLAVE;，并检查SHOW SLAVE STATUS\G中的Seconds_Behind_Master是否归零
锁粒度控制：mysqldump 的 --lock-tables vs --skip-lock-tables
mysqldump 默认启用 --lock-tables，对每个数据库逐表加 READ LOCAL 锁。这在从库上看似无害，实则会阻塞后续的复制 SQL 线程（因为复制线程需要写入，而锁未释放）。
- 用
--skip-lock-tables可跳过表级锁，但要求引擎为 InnoDB 且备份期间不能有 DDL 操作，否则导出数据可能不一致 - 更稳妥的选择是
--single-transaction：它依赖 MVCC 快照，不锁表，但仅对 InnoDB 有效；MyISAM 表仍会被隐式锁定 - 注意：如果从库开启了
innodb_lock_wait_timeout较短（如 10 秒），而备份耗时长，可能触发Lock wait timeout exceeded错误，需临时调高该值
Percona XtraBackup 的 --slave-info 和 --no-lock 实际效果
Percona XtraBackup 是物理备份工具，比逻辑备份更高效，但参数组合稍有不慎就会让主从关系断裂。
-
--slave-info会自动记录当前从库的Master_Log_File和Read_Master_Log_Pos到xtrabackup_slave_info文件中，这是重建新从库的关键依据 -
--no-lock跳过 FLUSH TABLES WITH READ LOCK，适用于只读从库；但它不等于“完全无锁”——InnoDB 内部仍有 checkpoint 和 buffer pool 刷脏页行为，仍可能短暂影响查询延迟 - 千万别在未
STOP SLAVE的情况下用--no-lock：此时备份点和复制位点不同步，恢复后从库大概率报错Could not find first log file name in binary log index file
备份窗口与主从延迟的隐蔽冲突
很多团队把备份定在凌晨 2 点，认为流量低就安全。但实际中，主从延迟常在备份开始后快速放大，尤其当主库刚经历一波大事务（如日终批处理）。
- 查看
SHOW SLAVE STATUS\G中的Seconds_Behind_Master，若大于 60 秒，应推迟备份，或先手动STOP SLAVE;等延迟归零 - 使用
pt-heartbeat监控真实延迟比Seconds_Behind_Master更可靠，后者在 SQL 线程空闲时可能显示为 0，但实际位点已滞后 - 备份脚本里必须加入延迟检测逻辑，例如：
mysql -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master:" | awk '{print $2}' | grep -q "^[0-9]\+$" && [ $(cat) -lt 30 ]否则自动化备份可能在延迟高峰强行启动，反而加剧问题
备份不是“跑完命令就结束”的事，真正难的是让备份动作和主从状态达成时间上的咬合。最常被忽略的，是 STOP SLAVE 和 START SLAVE 之间的窗口是否被监控覆盖，以及 xtrabackup_slave_info 是否真的被正确读取并用于后续恢复。
