从库备份更安全，核心原因是不干扰主库写入链路且规避锁表与慢查询拖垮主库的风险；必须停复制并确认Seconds_Behind_Master为0、校验GTID或位点一致性后执行，否则备份存在数据落后或中间态风险。
从库备份更安全，核心原因就一条：它不干扰主库的写入链路，且能规避备份期间锁表、慢查询拖垮主库的风险。
为什么不能直接在主库上跑 mysqldump？
主库承担全部写请求（INSERT/UPDATE/DELETE），而 mysqldump 默认加全局读锁（FLUSH TABLES WITH READ LOCK）或依赖一致性快照（需启用 --single-transaction）。但问题在于：
- 如果主库有长事务未提交，
--single-transaction会等待它结束，导致备份卡住，主库写入堆积 - 大表导出时 IO 和 CPU 占用飙升，直接影响主库响应延迟
- 命令行里明文写密码（如
mysqldump -u root -p123456）会被history记录，审计风险高 - 备份文件若存放在主库机器本地，一旦磁盘损坏或被入侵，备份和生产数据一并丢失
从库备份如何绕过这些坑？
从库是只读副本，天然适合做备份出口。实际操作中关键点在于：
- 必须先执行
STOP SLAVE;，再SHOW SLAVE STATUS\G确认Seconds_Behind_Master: 0，确保数据完全追平——否则备份的是“落后状态” - 备份前用
SELECT @@global.gtid_executed;（如果开启 GTID）或记录Relay_Master_Log_File+Exec_Master_Log_Pos值，用于后续恢复定位位点 - 推荐用专用账号连接从库，权限仅限
SELECT, SHOW VIEW, LOCK TABLES，禁止REPLICATION CLIENT（该权限对从库备份无必要，反而扩大攻击面） - 备份命令应使用
--defaults-extra-file指向权限为600的配置文件，彻底避免密码泄露
物理备份在从库上是否更可靠？
是，但有条件限制：
- 若用
cp -r /var/lib/mysql做冷备，必须先STOP SLAVE;+SET GLOBAL innodb_fast_shutdown=0;，保证 InnoDB 日志刷盘干净，否则恢复时可能报innodb: Database page corruption - 热物理备份（如
mysqlbackup）要求从库开启innodb_file_per_table且未使用加密表空间，否则备份包无法跨版本还原 - 从库的
datadir路径、MySQL 版本、字符集必须与目标恢复环境严格一致，否则ibdata1兼容性极易出错 - 注意：从库的 relay log 默认不自动清理，
relay-log-purge=ON必须开启，否则磁盘被 relay log 塞满导致复制中断
真正容易被忽略的是时间窗口控制——从库备份不是“只要停了复制就能随便 dump”，它依赖一个精确的同步断点。这个断点一旦没抓准，恢复出来的数据要么缺失最后几秒，要么包含未提交事务的中间态。所以每次备份后务必验证 gtid_executed 或 binlog position 是否可复现，而不是只看备份文件大小。
