必须用GTID而非file+position，因跨地域网络抖动易致主从断连，传统模式下binlog文件切换与位点错乱使CHANGE MASTER TO难以精准对齐；GTID通过gtid_executed集合自动计算并发送缺失事务，天然支持断点续传。
不能只靠 CHANGE MASTER TO 直接连远端主库做原生复制——跨地域链路下，Seconds_Behind_Master 失真、IO线程静默中断、GTID冲突、位点错乱是常态，不是配置不到位，而是协议层就不支持。
为什么必须用 GTID 而非 file+position？
跨地域同步中，网络抖动导致主从断连后，传统 master_log_file/master_log_pos 很难精准对齐：主库可能已切 binlog 文件，从库还在追旧文件末尾，手动 CHANGE MASTER TO 极易跳过或重复事务。
- GTID 模式下，从库只需上报已执行的 GTID 集合（
SELECT @@global.gtid_executed;），主库自动计算并发送缺失事务，语义上天然支持断点续传 - 必须同时开启
gtid_mode=ON和enforce_gtid_consistency=ON，否则像CREATE TEMPORARY TABLE这类非事务语句会被静默拒绝，下游同步卡死且无报错 - 验证是否生效：写入几条数据后执行
SHOW MASTER STATUS，确认Executed_Gtid_Set非空，且格式为UUID:1-5类结构
mysqlbinlog --read-from-remote-server 是最稳的跨地域拉取方式
不依赖从库状态机，规避 IO_THREAD 中断、relay log 满盘、slave_net_timeout 等原生复制链路脆弱点，适合公网长延时场景。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 命令必须带
--stop-never+--stop-never-slave-server-id=1001（server_id 全局唯一，避免与线上其他从库冲突） - 输出建议按时间戳轮转：
binlog_$(date +%Y%m%d_%H%M%S).bin，配合logrotate或定时脚本清理，mysqlbinlog不自动轮转 - 务必设
--raw输出二进制流，后续回放时可用mysqlbinlog --exclude-gtids='xxx' | mysql跳过已存在 GTID（仅 MySQL 5.7.20+ 支持） - 若目标只是存日志而非实时回放，直接推送到 S3/OSS 更可靠，RPO 可压至秒级
异地恢复时，SET GLOBAL gtid_purged 是关键前置动作
从对象存储或本地磁盘回放 binlog 前，如果目标库已存在部分 GTID（比如之前做过初始化导入），不显式设置 gtid_purged 会导致 RESET MASTER 后无法导入已有 GTID 的日志，报错 ERROR 1840 (HY000)。
- 先在源库查
SELECT @@global.gtid_executed;，记录该 GTID 集合 - 在目标库执行
SET GLOBAL gtid_purged = 'source_gtid_executed_value';（注意：必须在RESET MASTER之后、导入前执行） - 若用文件+位置方式恢复，需结合
mysqlbinlog -v --base64-output=DECODE-ROWS查看事件时间戳，再对齐业务日志确认“最后一条有效事务”位置
真正难的不是拉取，而是确认“哪一段 binlog 已被消费、哪一段还没落地”。GTID 提供了标识，但 gtid_purged 设置时机、exclude-gtids 的版本兼容性、server_id 冲突、以及 binlog_format=ROW + binlog_row_image=FULL 这些硬约束，漏掉任一环都会让同步链路在跨地域场景下静默失效。
