MySQL 8.0主从复制本身不等于高可用，必须配合MHA、Keepalived或MGR等自动故障转移机制才能实现业务不中断；仅配置主从需手动切换，属容灾而非高可用。
MySQL
编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。
下载
MySQL 8.0 主从复制本身不等于高可用，只配主从无法自动切换——主库一挂，应用连不上，你得手动改连接地址、启从库写权限、重定向流量。真要“业务不中断”，必须搭配
MHA、
Keepalived 或
MySQL Group Replication 这类自动故障转移机制。
确认 GTID 和 binlog_format 是否真正生效
GTID 是自动定位同步位置的基础，
binlog_format = ROW 是数据一致性的底线。但 MySQL 8.0 的“默认开启”不等于“已生效”，尤其在已有配置或升级环境中：
- 连主库执行
SHOW VARIABLES LIKE 'gtid_mode';，结果必须是 ON；enforce_gtid_consistency 也必须为 ON
- 执行
SHOW VARIABLES LIKE 'binlog_format';，值只能是 ROW —— 若为 STATEMENT 或 MIXED，写入 NOW()、UUID() 等非确定性函数时，主从必然不一致
- 修改
/etc/my.cnf 后必须重启 mysqld；SET GLOBAL 仅临时生效，重启即丢
创建复制账号时指定认证插件
MySQL 8.0 默认用
caching_sha2_password，但很多旧版中间件（如
MyCat 1.6、部分
JDBC 驱动、监控 agent）不兼容：
- 建号时显式指定：
CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';
- 建完立刻查：
SELECT user, host, plugin FROM mysql.user WHERE user = 'repl';，确保返回 mysql_native_password
- 若已建错，别折腾驱动版本，直接改：
ALTER USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';
从库启动复制前必须停 IO 线程并校验 GTID
用
GTID 搭建时，
CHANGE REPLICATION SOURCE TO（MySQL 8.0.23+）不接受
SOURCE_LOG_FILE/
SOURCE_LOG_POS，只认
SOURCE_AUTO_POSITION = 1：
- 启动前务必先执行
STOP REPLICA; —— 否则会报错 ERROR 3021 (HY000): This operation cannot be performed with a running slave io_thread
- 主库执行
SHOW MASTER STATUS;，确认 Executed_Gtid_Set 非空
- 从库执行
SELECT @@GLOBAL.gtid_executed;，全新从库应为空；已有数据需先 RESET SLAVE ALL; 再导入，否则 GTID 冲突导致复制失败
跨地域部署时网络与时间必须可控
主从延迟超过秒级，就谈不上“实时同步”，更别说高可用切换：
- 主从间网络延迟建议 ≤ 100ms；跨地域必须走专线或 SD-WAN（如 BGP/MPLS），公网直连不可靠
- 两节点必须严格时间同步：
chronyd 或 ntpd 对齐，误差 > 1s 可能导致 GTID 解析异常或 binlog 读取错位
-
read_only = ON 要设在从库，但不能只靠它防误写——它对 SUPER 权限用户无效，生产环境建议配合 super_read_only = ON
GTID 同步看似简单，但
gtid_executed 和
gtid_purged 的隐式变化、复制线程状态机跳变、以及网络抖动引发的
Retrying transaction 日志，都容易被忽略。真正上线前，一定要模拟主库宕机后从库是否能无干预接流、应用连接是否自动重连、切换脚本是否触发及时——配置只是起点，验证才是关键。
