直接在从库上执行mysqldump是安全且推荐的做法，前提是Slave_IO_Running和Slave_SQL_Running均为Yes、Seconds_Behind_Master≤5秒、GTID模式下Retrieved_Gtid_Set等于Executed_Gtid_Set；主库dump易因锁表或DDL冲突导致业务阻塞或一致性失败。
直接在从库上跑 mysqldump 是安全且推荐的做法，前提是复制未延迟、slave_sql_running 为 Yes，且你不需要主库实时一致性快照。
为什么不能在主库上无锁 dump 大库？
主库写入频繁时，mysqldump 默认启用 --lock-tables（或显式加 -x），会触发 FLUSH TABLES WITH READ LOCK —— 这会让所有写请求阻塞，业务可能超时。即使用了 --single-transaction，它只对 InnoDB 有效，且要求期间不能有 DDL（ALTER/DROP 等），而线上 DDL 往往不可控。
- MyISAM 表无法用事务保证一致性，必须锁表
-
--single-transaction不会锁表，但依赖 MVCC 快照，若备份耗时长，可能被 purge 线程清理掉 undo 日志，导致一致性失败 - 主库 dump 时若发生复制延迟突增，从库状态已落后，但 dump 文件仍会记录当时的
MASTER_LOG_FILE/POS，后续恢复后主从位置错位
从库 dump 必须确认的三个状态
执行前务必在从库 MySQL 客户端中检查：
-
SHOW SLAVE STATUS\G中Slave_IO_Running和Slave_SQL_Running都是Yes -
Seconds_Behind_Master接近 0（比如 ≤ 5 秒），避免 dump 出的数据比主库旧太多 -
Retrieved_Gtid_Set与Executed_Gtid_Set相等（GTID 模式下），说明 relay log 已全部执行完毕
只要这三个条件满足，mysqldump 就能拿到一个“逻辑上最终一致”的快照，且完全不影响主库。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
从库 dump 推荐参数组合
不加锁、保留 GTID、跳过复制元数据、兼容还原场景：
- 用
--single-transaction：InnoDB 表免锁，靠事务快照保证一致性 - 加
--set-gtid-purged=OFF：避免导出文件里写死SET @@GLOBAL.GTID_PURGED，否则还原到新实例会冲突（尤其当目标实例已有 GTID 历史） - 去掉
--master-data：从库 dump 不需要记录主库 binlog 位置；若硬要记，得用--master-data=2并确保从库开启了log_slave_updates，但这不是常规需求 - 显式禁用锁：
--skip-lock-tables（虽然--single-transaction已自动关掉--lock-tables，但加一层保险更清晰） - 带上
--routines --triggers --events：如果业务依赖存储过程或定时事件，漏掉会导致还原后功能异常
典型命令：
mysqldump -u root -p --all-databases --single-transaction --set-gtid-purged=OFF --skip-lock-tables --routines --triggers --events > slave_backup_$(date +%F).sql
还原时容易忽略的 GTID 冲突问题
从库 dump 文件里若含 SET @@GLOBAL.GTID_PURGED = '...'（由 --set-gtid-purged=AUTO 或默认行为触发），还原到已有数据的实例时会报错：ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty.
- 解决方法一：还原前先执行
RESET MASTER（清空所有 GTID 历史，仅限测试/新环境） - 解决方法二：dump 时强制
--set-gtid-purged=OFF，还原后手动在目标从库上CHANGE MASTER TO ...指向正确的主库位置 - 切勿在生产从库还原 dump 后直接
START SLAVE—— 必须先SHOW SLAVE STATUS核对Relay_Master_Log_File和Exec_Master_Log_Pos是否与 dump 时刻一致，否则可能跳过部分事务
真正麻烦的从来不是 dump 命令本身，而是还原后复制链路是否还连得上、GTID 是否对得上、有没有隐式跳过错误事件——这些都得靠 SHOW SLAVE STATUS 逐字段核对，不能只看 Yes/No。
