三台服务器搭 MySQL 集群，本质是在“成本”和“可用性”之间做一次精准取舍。三台机器最稳妥的两条路是：读多写少的业务走“一主两从 + Orchestrator 自动切换”，核心交易类业务走 MySQL Group Replication（MGR）三节点强一致方案。 下面把选型、成本、实操命令和避坑点一次讲透。
三台服务器能做MySQL集群吗？先划清架构边界
三台机器到底能扛住什么
三台物理机或云主机，能覆盖的是“单点故障自动恢复”这一层，而不是“双机房容灾”，行业共识认为， MySQL 集群的可用性下限由副本数决定，三节点刚好能凑出“一主两从”或“三成员 MGR”，在单台宕机时保留多数派,它的边界很清晰：
- 能扛：单台服务器硬件故障、MySQL 进程崩溃、单机磁盘损坏。
- 扛不住：机房级断电、网络分区导致的脑裂（需要仲裁节点或跨机房部署）。
- 别指望：三台机器做出金融级同城双活,那至少是五节点起步。
三种主流形态的取舍
在实际落地里,三台服务器常见的形态就三种：
- 一主两从 + 半同步复制：写走主库，读分摊到从库，配合 Orchestrator 做故障切换。
- MGR 三成员单主模式：基于 Paxos 变体协议，事务提交需要多数派确认,数据一致性强。
- 主从 + Keepalived 虚拟 IP：老系统改造常用，切换靠 VIP 漂移,配置简单但切换有脑裂风险。
选哪种，取决于你的业务能不能容忍“切换瞬间丢几条事务”。
小公司三台服务器MySQL高可用方案怎么选
一主两从 + Orchestrator：最省心的读写分离路子
这是中小团队落地最多的组合，主库承担写入，两个从库分担查询，Orchestrator 持续探测主库健康状态，发现异常后自动把其中一个从库提升为主库,并让另一个从库指向新主。
适合的场景很具体：日订单几千到几万、读请求明显多于写请求、团队里没有专职 DBA，缺点是切换过程中存在秒级不可写窗口，异步复制下还可能丢最后一批事务；开启半同步复制（rpl_semi_sync_master_enabled=ON）能把窗口压到最小,代价是写入延迟略微上升。
MGR 三节点：强一致优先的选择
MGR 把三台机器组成一个复制组，事务在提交前要经过组内多数派认证，三节点意味着能容忍一台宕机，剩两台仍构成多数派,集群继续可写。
它的代价也很实在：写入要等多数派确认，网络往返直接影响事务延迟；对 innodb_flush_log_at_trx_commit 和网络质量要求高；大事务、无主键表容易触发认证冲突，如果你的业务是支付、库存扣减这类不能丢数据的场景,这些代价是值得的。
主从 + Keepalived VIP：老系统改造常见做法
很多传统企业的内部系统还在用这套，两台做读写分离，第三台做延迟从库或备份节点，Keepalived 通过 VIP 对外提供统一入口，优点是改造成本低、运维人员熟悉；缺点同样明显VIP 漂移依赖脚本判断，主库“假死”时容易双主写入，这类方案建议加一个仲裁脚本或引入外部健康检查，别只靠 vrrp_script 里的一个 ping。
MySQL MGR和主从复制哪个更适合三台服务器
把两者放在三台服务器的约束下对比,结论会更清楚：
| 对比维度 | 一主两从 + Orchestrator | MGR 三节点单主 |
|---|---|---|
| 数据一致性 | 异步或半同步，切换可能丢事务 | 多数派认证，强一致 |
| 写入延迟 | 低 | 略高，受网络往返影响 |
| 故障切换 | 依赖外部组件，秒级 | 组内自动选举，通常更快 |
| 运维复杂度 | 中等，需维护 Orchestrator | 较高，参数和网络要求严 |
| 适合业务 | 读多写少、可容忍少量丢失 | 交易、账务、库存 |
一句话总结：能接受“切换时可能丢最后几条事务”就选主从加切换工具，不能接受就上 MGR。 三台服务器这个规模，没必要为了“看起来先进”硬上 MGR,也没必要为了省事在核心库上用纯异步复制。
三台服务器搭建MySQL集群的成本要花多少钱
成本这块拆成三块看更实在。
硬件或云主机：据主流云厂商公开报价页，4 核 8G 规格的云服务器按年付，单台常见在几千元量级，三台一年下来通常在万元上下浮动；如果选 8 核 16G 并配 SSD 云盘，预算还要往上走一档,自建物理机则要考虑机房托管和带宽费用。
软件：MySQL 社区版免费，Orchestrator、ProxySQL、Keepalived 都是开源组件，这部分几乎零成本，企业版或云厂商的托管数据库服务按规格计费,三节点高可用实例的价格通常是单机的两到三倍。
隐性成本：备份存储、监控告警、跨可用区网络流量，以及最容易被低估的人力，一套没有自动化切换的三节点集群，故障时靠人凌晨爬起来切库,这个成本比服务器本身贵得多。
实操：三台服务器部署MGR的完整路径
环境与前置检查
准备三台同规格机器，假设 IP 为 192.168.1.11、12、13，系统 CentOS 7 或 Rocky 8，MySQL 8.0.3x 社区版,先做三件事：
- 关闭 SELinux，防火墙放行 3306 和 33061（MGR 通信端口）。
- 三台机器配置
/etc/hosts，保证主机名互 ping 通。 - 时间同步，
chronyd或ntpd任选其一,节点间时间偏差过大会影响认证。
my.cnf 关键参数
三台机器的 server_id 必须不同,其余保持一致：
[mysqld] server_id=11 gtid_mode=ON enforce_gtid_consistency=ON binlog_checksum=NONE log_bin=mysql-bin log_slave_updates=ON binlog_format=ROW master_info_repository=TABLE relay_log_info_repository=TABLE transaction_write_set_extraction=XXHASH64 plugin_load_add='group_replication.so' group_replication_group_name="aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee" group_replication_start_on_boot=OFF group_replication_local_address="192.168.1.11:33061" group_replication_group_seeds="192.168.1.11:33061,192.168.1.12:33061,192.168.1.13:33061" group_replication_single_primary_mode=ON group_replication_bootstrap_group=OFF
group_replication_group_name 必须是合法 UUID,三台填同一个值。
引导与加入集群
在三台机器上分别初始化并启动 MySQL,然后创建复制账号：
SET SQL_LOG_BIN=0; CREATE USER 'repl'@'%' IDENTIFIED BY 'YourStrongPass'; GRANT REPLICATION SLAVE, BACKUP_ADMIN ON . TO 'repl'@'%'; SET SQL_LOG_BIN=1; CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='YourStrongPass' FOR CHANNEL 'group_replication_recovery';
在 11 号节点上引导集群：
SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF;
12、13 号节点直接执行 START GROUP_REPLICATION; 即可加入，注意引导参数只能在一个节点上开一次,多开会形成两个独立组。
验证与故障演练
SELECT MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
三个成员状态都应为 ONLINE，其中一个是 PRIMARY，上线前务必做一次故障演练：直接 kill -9 主库 MySQL 进程，观察剩余两个节点是否在数十秒内选出新主，应用连接是否通过中间件自动重连，没演练过的集群,等于没搭。
华东地区机房部署三台MySQL服务器要注意什么
如果服务器落在上海、杭州这类华东机房，有几个细节值得提前确认，跨可用区部署时，三台机器别全塞进同一个可用区，否则机房局部故障会一锅端；但跨区网络延迟会直接影响 MGR 的提交性能，建议先压测节点间 RTT，超过 2 毫秒就要重新评估，另外华东地区夏季用电高峰，部分老旧机房有供电波动记录，选机房时问清楚 UPS 和柴发的切换记录，带宽方面，主从复制和备份传输会吃掉不少内网流量，按峰值写入量估算,别等同步延迟飙到几分钟才想起扩容。
三台服务器MySQL集群Q&A
Q1：三台服务器MySQL集群必须用奇数节点吗？
多数派机制要求投票成员为奇数，三节点正好满足，如果只有两台，单台故障后无法形成多数派，集群会停止写入，所以两台做 MGR 意义不大,不如退回主从加半同步。
Q2：三台服务器MySQL集群怎么备份才不影响主库性能？
在其中一个从库或 MGR 的次要节点上执行物理备份，用 Percona XtraBackup 配合 --safe-slave-backup，并开启 log_slave_updates 保证 GTID 连续，备份窗口安排在业务低峰，同时监控从库延迟,别让备份把复制线程拖垮。
Q3：三台服务器MySQL集群能撑住多大的业务量？
瓶颈通常不在节点数量，而在单机规格和写入模式，4 核 8G 配 SSD 的三节点 MGR，日订单量几万的业务跑起来没什么压力；如果单表过亿、写入 QPS 上千，就该考虑分库分表或提升单机规格，而不是继续在三台机器上堆参数，据工信部相关产业报告，国内中小企业数据库选型中，三节点高可用架构仍是主流配置之一,这与成本和运维复杂度的平衡直接相关。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/782357.html
