为什么要先拿一致快照与位点
从库要从主库的某一个精确时刻开始重放，所以建从库的第一步是同时取得两样东西：一份该时刻的一致性数据快照，和与之对应的 binlog 位点或 GTID 集合。顺序错了就出事：先导数据后记位点会漏掉中间产生的变更，先记位点后导数据则可能重复应用，两种情况都需要重新搭一遍。
基本信息
| 适用平台 | MySQL 5.7 / 8.0 传统主从复制 |
|---|---|
| 经典做法 | FLUSH TABLES WITH READ LOCK 锁写后取位点再导出 |
| 取位点命令 | SHOW MASTER STATUS（8.0.22+ 为 SHOW BINARY LOG STATUS） |
| GTID 环境 | 记录 @@GLOBAL.gtid_executed 与 gtid_purged |
| 自动方案 | mysqldump --source-data=2、XtraBackup 均自带位点 |
典型使用场景
- 新上线一台从库，需要与主库对齐后再开始复制
- 故障后重建损坏的从库，避免长时间追赶 binlog
- 扩容读副本用于分摊查询压力
- 迁移到新机房：先在新环境搭从库，再切换流量
- 演练恢复流程：验证从零搭建从库所需时间
经典流程（会话 A 加锁，会话 B 取位点）
经典流程（会话 A 加锁，会话 B 取位点）
-- 会话 A：加全局读锁，阻塞写入
FLUSH TABLES WITH READ LOCK;
-- 会话 B：在同一窗口内记录位点
SHOW BINARY LOG STATUS; -- 8.0.22+；旧版本用 SHOW MASTER STATUS
-- 记下 File: mysql-bin.000045 与 Position: 12345678
-- 该窗口内用 mysqldump 导出或 XtraBackup 拍快照
-- 回到会话 A：解除锁定
UNLOCK TABLES;GTID 环境与工具自带位点
GTID 环境与工具自带位点
# GTID 模式：记录已执行集合，恢复后设置 gtid_purged
mysql -e "SELECT @@GLOBAL.gtid_executed"
# mysqldump 直接把位点写进导出文件头部
mysqldump -uroot -p --single-transaction --source-data=2 --all-databases > all.sql
head -30 all.sql | grep -E 'CHANGE REPLICATION SOURCE|GTID_PURGED'
# XtraBackup 在备份目录内记录位点
cat /data/backup/xtra_2026-10-12/xtrabackup_binlog_info位点获取方式对比
| 方式 | 锁写时长 | 适用场景 |
|---|---|---|
| FTWRL 手工取位点 | 需短暂全局锁写 | 传统流程，非 InnoDB 表也一致 |
| mysqldump --source-data=2 | 仅 InnoDB 走一致性快照 | 小中型库，导出即带位点 |
| XtraBackup | 备份过程不阻塞写入 | 大库、要求恢复快 |
| Clone Plugin | 实例级克隆（8.0.17+） | 新副本快速对齐，减少手工步骤 |
并行导出工具与快照类备份能把位点写在产物里，比手工记忆更不容易出错；使用前先确认版本是否支持 source-data 这类新参数名。
FTWRL 会阻塞全部写入，业务高峰执行会直接造成写入积压。窗口要尽量短：先在另一个会话准备好导出脚本，取完位点立刻解锁。