能，但需手动补全监控、切换逻辑和断网重连策略；必须开启GTID、ROW格式、relay_log_recovery；调优heartbeat、retry_count和net_timeout；从库需关闭read_only、校验server_id及时区；云灾备实例封装深、可控性差。
主从复制能实现异地灾备吗？
能，但不是开箱即用的“灾备”——它只是基础能力。MySQL 主从复制本身不保证数据零丢失、不自动切换、不校验跨地域网络抖动下的 GTID 一致性。你得自己补上监控、切换逻辑和断网重连策略。
常见错误现象：Seconds_Behind_Master 持续为 NULL 或飙升；从库报错 Could not parse relay log event entry；主库宕机后从库无法升主（read_only=1 没关、GTID mode 不一致）。
- 必须开启
gtid_mode=ON+enforce_gtid_consistency=ON，否则跨地域延迟突增时容易丢事务 - 主库
binlog_format必须是ROW，语句级日志在异地网络分区下极易产生主从不一致 - 从库务必设置
relay_log_recovery=ON，否则断电或强制重启后可能跳过部分中继日志
异地网络不稳定，怎么避免复制中断？
云环境跨地域链路（比如华东到华北）RTT 高、偶发丢包，CHANGE MASTER TO 默认参数扛不住。关键不是调大超时，而是让复制进程更“耐摔”。
使用场景：主库在阿里云杭州，从库部署在腾讯云北京，两地专线未打通，走公网。
- 在从库执行：
CHANGE MASTER TO master_heartbeat_period = 30.0（单位秒），比默认 0 更早触发心跳探测 - 加参数：
MASTER_RETRY_COUNT = 86400（一天），避免一次失败就停掉 SQL 线程 - 禁用
slave_net_timeout的默认值（3600），设为60：让 IO 线程更快感知连接断开并重连，而不是傻等一小时 - 别依赖
auto-reconnect—— MySQL 官方已弃用该选项，且不作用于复制线程
从库能直接当热备顶上去吗？
不能直接顶，必须提前验证和预置操作。热备不是“挂了就能切”，是“随时可切、切完可用”。最常踩的坑是权限、配置、时间戳三不一致。
性能 / 兼容性影响：开启 log_slave_updates 是必须的（否则从库无法再做下级从库），但它会增加磁盘 I/O 和 relay log 写入延迟，在高写入场景需预留 15%~20% CPU 余量。
- 从库必须关闭
read_only=OFF（注意不是0），且确认super_read_only=OFF，否则STOP SLAVE后仍无法写入 - 检查
SHOW VARIABLES LIKE 'server_id'是否唯一——主从 server_id 相同会导致 GTID 冲突，切完立刻复制失败 - 用
SELECT UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(UTC_TIMESTAMP())核对主从系统时区偏差，>1 秒就可能引发基于时间的分库逻辑错乱 - 备份
mysql.user表结构和账号（尤其 host 字段含 IP 的），云数据库常限制本地登录，切完要立刻恢复访问路径
云厂商控制台里的“灾备实例”是不是更省事？
它封装了主从，但把底层细节藏得更深——你没法改 relay_log_space_limit，看不到 Retrieved_Gtid_Set 实时进度，出问题只能提工单等反馈。适合低 SLA 要求场景，不适合金融、订单类业务。
容易被忽略的地方：云厂商的“一键灾备”通常不包含应用层 DNS 切换、连接池刷新、缓存双删逻辑。数据库切过去了，APP 还连着旧地址，或者缓存没清，结果查到脏数据——这锅不归 MySQL 背。
