跨VPC MySQL主从复制必须启用SSL加密并配置require_secure_transport=ON，从库授权需精确匹配NAT出口IP，slave_net_timeout应调至120以避免重连风暴，GTID模式下须设master_info_repository=TABLE。
不能直接用公网IP配主从，必须走VPC对等连接或云联网，否则Seconds_Behind_Master会持续飙升甚至中断。
跨VPC主从复制必须关闭require_secure_transport？
不是必须关闭，而是必须开启——这是硬性安全前提。云环境跨VPC通信虽走内网通道，但若未启用SSL/TLS加密，REPLICATION SLAVE账号的密码仍可能在传输中被截获（尤其经由云厂商中转节点时）。
- 主库需配置
require_secure_transport=ON，并生成CA/Server证书，启用ssl_mode=REQUIRED - 从库
CHANGE REPLICATION SOURCE TO命令中必须显式指定MASTER_SSL=1、MASTER_SSL_CA等参数 - 验证是否生效：
SHOW SLAVE STATUS\G中检查Slave_IO_SSL_Allowed: Yes和Seconds_Behind_Master是否稳定在0~1之间
从库连接主库时提示Access denied for user 'repl'@'x.x.x.x'
错误根源几乎全是授权范围不匹配。跨VPC后，从库真实出口IP不再是内网直连IP，而是NAT网关或云联网出口IP，GRANT语句里的Host值必须精确对应这个IP。
- 先在从库执行
SELECT @@hostname;和SELECT SUBSTRING_INDEX(USER(), '@', -1);确认实际连接来源IP - 主库执行授权时，不能写
'repl'@'%'或'repl'@'10.0.%'，必须写成'repl'@'203.205.128.45'（即从库出口公网IP）或'repl'@'172.16.0.0/16'（若已知对方VPC CIDR） - 授权后刷新权限：
FLUSH PRIVILEGES;，且确认主库bind_address未绑定为127.0.0.1
slave_net_timeout设太小会导致IO线程频繁断连
跨VPC链路存在固有延迟（通常50~200ms），默认slave_net_timeout=60在弱网波动时会触发重连风暴，表现为Slave_IO_Running: Connecting反复切换。
- 建议将
slave_net_timeout调至120，同时配套调整net_read_timeout=60和net_write_timeout=60 - 若使用GTID模式，还需确认
master_info_repository=TABLE（避免文件型存储在重启后丢失位点） - 上线前务必用
mysqladmin ping -h <master_ip> -u repl -p --sleep=10 --count=100</master_ip>模拟长连接稳定性
真正容易被忽略的是：跨VPC主从一旦建立，SHOW PROCESSLIST里看到的从库连接Host显示的是NAT出口IP而非原始内网IP，排查问题时若只查本地路由表会误判网络不通；务必以云控制台的“VPC流日志”或tcpdump -i any port 3306抓包确认实际通信路径。
