mysql如何搭建高可用环境_mysqlHA环境配置与部署

mysql高可用需在主从复制上叠加故障检测、角色切换和客户端路由三层能力，推荐group replication（强一致性，需5.7.17+/8.0+）或proxysql+orchestrator（适配现有架构），禁用keepalived+vip方案。

MySQL 主从复制是高可用的基础，但单靠它不够

主从复制本身不提供自动故障转移能力。当主库宕机，必须人工干预切换从库为主库，期间服务中断、数据可能丢失。真正可用的 MySQL HA 环境，需要在复制之上叠加故障检测、角色切换和客户端路由三层能力。

常见组合方案有：MySQL Group Replication（官方原生 MGR）、Percona XtraDB Cluster（PXC）、MHA（已停更，慎用）、Orchestrator + ProxySQL 或 MaxScale。目前生产推荐优先评估 Group Replication 或 ProxySQL + 异步主从。

• 如果要求强一致性且能接受 3 节点最低部署，选 Group Replication（基于 Paxos，支持多写或单主模式）
• 如果已有成熟主从架构，只想加一层高可用调度，ProxySQL + Orchestrator 更轻量、易调试
• 避免直接用 keepalived + VIP 做主库漂移：无法感知 MySQL 实例是否真的可服务（比如 crash 后 mysqld 进程未起来，VIP 却已切过去）

用 Group Replication 搭建单主模式三节点集群

这是目前最可控、无需第三方组件的原生方案。注意：必须使用 MySQL 5.7.17+ 或 8.0+，所有节点需开启二进制日志、启用 GTID，并关闭 binlog_checksum（MySQL 5.7）或设为 NONE（8.0）。

关键配置项（my.cnf 中）：

server_id=1 gtid_mode=ON enforce_gtid_consistency=ON binlog_format=ROW plugin_load_add='group_replication.so' transaction_write_set_extraction=XXHASH64 group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=OFF group_replication_local_address="node1:33061" group_replication_group_seeds="node1:33061,node2:33061,node3:33061" group_replication_bootstrap_group=OFF

• 每个节点 server_id 和 group_replication_local_address 必须唯一；group_replication_group_seeds 是初始发现地址，所有节点写全
• 首次启动时，仅在一个节点执行 SET GLOBAL group_replication_bootstrap_group=ON;，再 START GROUP_REPLICATION;，之后立即关掉 bootstrap（SET GLOBAL group_replication_bootstrap_group=OFF;）
• 其余节点直接执行 START GROUP_REPLICATION; 即可加入
• 验证状态：查 performance_schema.replication_group_members，状态必须为 ONLINE；查 replication_group_member_stats 确认事务同步无延迟

ProxySQL + Orchestrator 实现自动故障转移

这套组合更适合已有异步主从环境的升级。Orchestrator 负责探测主库健康、选举新主、重置从库指向；ProxySQL 负责将写请求只发给当前主库，读请求按权重分发到从库。

Orchestrator 配置要点：

• 必须开启 detectClusterAlias 和 auditLogFile，便于追踪切换动作
• FailureDetectionPeriodBlockMinutes 建议设为 1（分钟），避免误判瞬时抖动
• 在 raft 模式下运行（多实例高可用），否则单点 Orchestrator 故障会导致整个 HA 失效

ProxySQL 关键操作：

• 通过 mysql_servers 表注册后端节点，用 hostgroup_id 区分写组（如 10）和读组（如 20）
• 用 mysql_query_rules 规则匹配 select 语句并路由到读组；显式含 /*+ MAX_EXECUTION_TIME(1000) */ 的查询也可强制走读组
• Orchestrator 切换完成后，需调用 ProxySQL REST API 或写入 mysql_servers 表更新主库 hostgroup_id，否则写流量仍打向旧主

最容易被忽略的细节：网络与权限

所有高可用组件都极度依赖底层网络稳定性。跨机房部署 MGR 或 ProxySQL 时，group_replication_communication_max_message_size 默认 10M，但公网 MTU 小、丢包率高，建议降至 1M 并开启 group_replication_compression_threshold。

权限方面：

• MGR 节点间通信需 REPLICATION SLAVE、REPLICATION CLIENT、SUPER（8.0+ 改为 GROUP_REPLICATION_ADMIN）
• Orchestrator 连接 MySQL 需要 PROCESS、REPLICATION SLAVE、SUPER 权限，且必须允许从 Orchestrator 所在主机连接
• ProxySQL 管理接口默认监听 6032，但生产必须改密码、限制访问 IP，否则等于裸奔

别低估 DNS 解析失败的影响：Orchestrator 和 ProxySQL 内部大量使用主机名注册节点，一旦 DNS 不稳，节点会反复“失联→恢复→再失联”，触发无意义切换。