必须走内网。云厂商内网带宽千兆/万兆、延迟0.1ms级；公网受地域、运营商、防火墙及出向限速影响，延迟达秒级甚至分钟级，易引发Seconds_Behind_Master上涨、IO/SQL线程中断及连接超时等问题。
MySQL主从同步走公网还是内网？
必须走内网。云厂商的内网带宽通常是千兆甚至万兆，延迟在0.1ms级；走公网不仅受地域、运营商、防火墙限制，还可能触发云平台的出方向流量限速，同步延迟直接拉到秒级甚至分钟级。
常见错误现象：Seconds_Behind_Master 持续上涨、SHOW SLAVE STATUS 中 IO_Running 或 SQL_Running 变为 No，查日志发现大量 Connection timed out 或 Lost connection to MySQL server。
- 确认主库和从库部署在同一地域、同一可用区（AZ），且属于同一VPC（或已打通对等连接）
- 检查主库
bind_address是否设为0.0.0.0或内网IP，而非127.0.0.1 - 从库连接主库时，
CHANGE MASTER TO MASTER_HOST必须填内网IP（如10.0.1.5），不能填公网域名或EIP - 安全组/网络ACL需双向放行：主库3306端口入方向（来源为从库内网IP），从库出方向不限制（但建议限制目标为主库内网IP+3306）
mysqldump + 内网导入太慢？换 mysqlpump 或 mydumper
mysqldump 是单线程、锁表（除非加 --single-transaction）、文本导出，对百GB级库基本不可用；而 mysqlpump（MySQL 5.7+）和 mydumper（第三方）支持多线程、分表导出、无锁（基于一致性快照），内网传输时吞吐能提3–5倍。
使用场景：首次全量迁移、跨版本升级前的数据导出、需要保留表结构+数据分离操作。
-
mysqlpump默认并发4线程，可调--default-parallelism=8，但注意主库CPU和IOPS承受能力 -
mydumper更灵活，推荐搭配myloader使用，导入时加-t 8控制线程数，避免从库写入堆积 - 别用
gzip压缩再传——内网带宽充足，压缩/解压反而吃CPU，拖慢整体时间；如确需压缩，选zstd -T0（多线程压缩） - 导出时避开业务高峰，并确认
max_allowed_packet足够大（建议 ≥512M），否则mysqlpump可能报Packets larger than max_allowed_packet
GTID模式下主从切换失败？检查 enforce_gtid_consistency 和 gtid_mode
云数据库大多默认开启GTID，但旧MySQL实例常关闭。若主库开了GTID而从库没开，或两边 gtid_mode 级别不一致（如主库是 ON，从库是 ON_PERMISSIVE），CHANGE MASTER TO 会报错 ERROR 1777 (HY000)，同步根本启不来。
参数差异直接影响兼容性：GTID要求所有事务可唯一标识，禁止 CREATE TEMPORARY TABLE、非事务引擎写入、sql_log_bin=OFF 等操作。
- 主从都执行：
SELECT @@gtid_mode, @@enforce_gtid_consistency，确保均为ON - 若旧库未开GTID，不要强行开启——先停写、
mysqldump --set-gtid-purged=OFF导出，再在云库上关GTID导入（仅限测试环境） - 云数据库控制台创建的实例，通常强制GTID，此时本地主库必须同步开启，且需提前清理
mysql.gtid_executed表中残留记录（用RESET MASTER谨慎） - 开启GTID后，
CHANGE MASTER TO不再用MASTER_LOG_FILE/MASTER_LOG_POS，改用MASTER_AUTO_POSITION = 1
同步延迟突然飙升？优先查 innodb_io_capacity 和从库磁盘IOPS
内网带宽不是瓶颈，但云数据库的云盘IOPS往往受限（尤其通用型实例）。主库写入快，从库SQL线程单线程重放，一旦磁盘写不过来，Seconds_Behind_Master 就会指数增长，且 SHOW PROCESSLIST 里看到大量 Updating 或 Writing to net 状态。
性能影响比带宽更隐蔽：即使监控显示CPU、内存正常，IOPS打满也会卡住同步。
- 查从库磁盘：Linux下用
iostat -x 1，重点关注%util（持续 >90% 即饱和）和await（>20ms 表示响应慢） - 调整从库
innodb_io_capacity（设为云盘实测IOPS的70%，如1200→800），并配innodb_io_capacity_max = 2 * innodb_io_capacity - 避免在从库执行大查询——
SELECT会争抢Buffer Pool和I/O资源，加重延迟；必要时加/*+ MAX_EXECUTION_TIME(3000) */限流 - 云厂商提供的“只读实例”通常自带I/O优化，比自建从库更稳；如果延迟顽固，优先考虑切过去，而不是调参
内网带宽只是同步的“高速公路”，真正卡住的往往是主库的binlog生成节奏、从库的磁盘吞吐、以及GTID这类一致性机制带来的隐式约束——这些地方不动手查指标，光换网络没用。
