直接在从库备份需确认复制状态正常、引擎兼容并正确使用--dump-slave=2等参数，避免start slave语句和位点错误，物理备份须排除mysql.slave_%表且确保sql线程暂停。
直接在从库上做备份，主库完全无感知——但前提是连接对、锁对、位点记对，否则备份不可用或复制断裂。
确认从库连接和复制状态再动手
很多脚本一上来就跑 mysqldump，结果连错了库（连到主库）或压根没查延迟。备份前必须登录从库执行：
-
SHOW SLAVE STATUS\G，确认Slave_IO_Running和Slave_SQL_Running都是Yes -
Seconds_Behind_Master必须稳定（比如 ≤ 5 秒），不能持续上涨；若延迟大，先等追平或业务低峰再操作 - 检查
mysql库下表引擎：SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='mysql' AND TABLE_NAME IN ('slave_master_info', 'slave_relay_log_info');若含MyISAM，--single-transaction对这些表无效，得靠--safe-slave-backup或手动停 SQL 线程
mysqldump 备份从库：参数组合不能错
从库逻辑备份不是简单加 --single-transaction 就完事。它不干扰复制的前提是避开系统表锁、跳过启动语句、记录正确位点：
- 必须加
--skip-slave-start：否则 dump 文件里会带START SLAVE，还原后直接触发复制错乱 - 不要用
--master-data=2（那是为主库设计的），改用--dump-slave=2，它输出的是CHANGE MASTER TO所需的 relay log 位置，对应主库真实已执行点 - 加
--single-transaction仅对 InnoDB 表有效；若从库启用了log-slave-updates且自己也写 binlog，mysql库里部分表可能是 MyISAM，此时要配合--skip-lock-tables+--skip-triggers避免隐式锁 - 导出后立刻检查 dump 文件开头：确认没有
START SLAVE、SLAVE START，且有类似-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000123', MASTER_LOG_POS=45678;的注释行
xtrabackup 物理备份从库：跳过复制元数据是关键
物理备份快、适合大库，但从库的 mysql.slave_master_info 这类表是运行时状态，直接拷贝过去会导致新实例复制指向错误 master：
- 必须排除复制系统表：
--exclude='mysql\.slave_%'（注意反斜杠转义） - 不要用
--no-lock：虽然 InnoDB 表可免锁，但mysql库中 MyISAM 表（如general_log）仍需锁，应强制用--safe-slave-backup - 执行后盯日志：必须看到
Waiting for slave SQL thread to stop→done，否则 SQL 线程没真正暂停，备份位点不准 - 备份完成立即
START SLAVE SQL_THREAD;，别等脚本自动处理——有些封装工具会漏这步
备份后最容易被忽略的三件事
脚本跑通 ≠ 备份可用。线上出问题往往卡在这几个细节：
- 没校验 dump 文件是否完整：用
tail -n 20 backup.sql | grep '^-- Dump completed'确认结尾正常，而不是被kill -9或磁盘满截断 - 没验证位点可恢复：拿备份文件 + 对应 binlog 片段，在测试机上走一遍
mysql + <code>mysqlbinlog binlog.000123 | mysql，确认SHOW SLAVE STATUS能正常启动 - 没清理旧备份的 relay log 依赖：如果从库开启了
relay_log_purge=OFF，备份时没删掉旧 relay log，还原后可能因缺失 relay 日志导致START SLAVE报错Could not find first log file name in binary log index file
