如何配置MySQL 8.0的双机主备（MHA）高可用架构？-mysql教程-PHP中文网

mha要求至少三节点（1主+2从），因其需通过比较多个从库的gtid/日志位点选举数据最完整的节点为新主，并补全binlog以保障一致性；双节点无法验证数据完整性且故障后无同步源。

如何配置mysql 8.0的双机主备（mha）高可用架构？

MySQL 8.0 的双机主备（严格说应是“一主多从 + MHA 管理”）不能靠两台机器简单互备实现；MHA 本身不支持双机纯主备拓扑，它依赖至少一个额外的从库来判断数据新鲜度、补全日志差异——少于三节点时，故障转移无法保证数据一致性。

为什么 MHA 要求至少三节点（1 主 + 2 从）

MHA Manager 在主库宕机时，必须比较所有从库的 Exec_Master_Log_Pos 和中继日志内容，选出最接近主库状态的从库作为新主。若只有 1 个从库：

无法验证该从库是否真的收到了全部 binlog（比如网络抖动导致部分 relay log 未写入）
切换后其他节点（此时只剩自己）无法被同步，集群退化为单点，且无回滚/补偿能力
masterha_master_switch --manual 会直接报错：FATAL Can't get current master from any slaves

官方文档明确要求最小部署为 1 主 + 2 从，第三节点可复用为 MHA Manager（但不建议与 MySQL 同机）。

MySQL 8.0 必须关闭 caching_sha2_password 插件

MHA Node 和 Manager 使用 Perl DBI 连接 MySQL，至今（2026 年）仍不支持 MySQL 8.0 默认的 caching_sha2_password 认证插件，连接会卡在 Authentication plugin 'caching_sha2_password' cannot be loaded。

正确做法是在创建复制用户和 MHA 检查用户时显式指定旧插件：

CREATE USER 'repl'@'%' IDENTIFIED WITH mysql_native_password BY 'ReplPass123!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

同样，MHA 配置文件 /etc/mha/app1.cnf 中的 user 和 password 对应的账号也必须用该插件创建；仅改 default_authentication_plugin 全局参数无效。

GTID 开启后 CHANGE MASTER TO 语法必须用 SOURCE_ 前缀

MySQL 8.0.23+ 已废弃 CHANGE MASTER TO，强制使用 CHANGE REPLICATION SOURCE TO。若混用旧语法，执行会报错：

MySQL（Linux）

MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。

下载

ERROR 1785 (HY000): Statement violates GTID consistency: UPDATE/INSERT/DELETE on table without PRIMARY KEY is prohibited.

这不是主键问题，而是语句被拒绝的误导提示。实际原因就是语法过时。正确写法（以从库连接主库为例）：

CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.1.10',
  SOURCE_USER='repl',
  SOURCE_PASSWORD='ReplPass123!',
  SOURCE_PORT=3306,
  SOURCE_AUTO_POSITION=1;

注意：SOURCE_AUTO_POSITION=1 是 GTID 模式下唯一合法方式，不能再用 MASTER_LOG_FILE + MASTER_LOG_POS。

keepalived VIP 切换脚本必须检查 MySQL 实例存活，而非仅端口

很多教程只用 nc -z $MYSQL_HOST 3306 判断 MySQL 是否可用，这极不可靠——mysqld 进程可能僵死、线程卡住、或处于 RECOVERY 状态，端口通但无法执行 SQL。

真正有效的健康检查应执行轻量查询：

mysql -urepl -pReplPass123! -h127.0.0.1 -e "SELECT 1" &>/dev/null

并配合 timeout 3 防止 hang 住。该命令需写入 keepalived 的 vrrp_script，且脚本权限设为 700（keepalived 以非 root 用户运行时需额外授权）。

最易被忽略的一点：MHA 自动故障转移完成后，原主库恢复时不会自动重入集群；必须手动执行 RESET REPLICA ALL + START REPLICA，否则它永远停留在 Retrieved_Gtid_Set 不更新的状态——这个动作不在任何 MHA 脚本里，得靠运维巡检或外部监控触发。