mysql如何部署集群

MySQL集群不是部署装个软件就完事的东西。我见过太多团队直接上MGR（MySQL Group Replication），集群结果被脑裂和流控折腾到半夜回滚。部署选型之前先想清楚：你要的集群是高可用，还是部署读写扩展，还是集群两者都要。这三个目标对应的部署方案完全不同。

单主复制加MHA或者Orchestrator，集群是部署中小规模最稳的路子。一个主节点扛写入，集群两个从节点做热备，部署配合VIP漂移或者ProxySQL做路由。集群主库挂了，部署MHA在10到30秒内把从库提上来。集群这套方案运维成本低，部署坑也少。缺点是写入没法扩展，主库该扛多少还是多少。

如果读压力大，一主多从加ProxySQL做读写分离就够了。ProxySQL的query rules能把SELECT打到从库，INSERT/UPDATE/DELETE走主库。配置不复杂，但要注意主从延迟。延迟超过阈值的从库，ProxySQL可以自动摘掉。这个阈值设多少？看业务能忍多久的脏读。电商订单查详情，延迟2秒可能就出问题；后台报表跑分析，延迟30秒也无所谓。

MGR适合需要自动故障切换且能接受性能损耗的场景。它基于Paxos协议，多数派确认才算提交。三个节点起步，五个节点更稳。但MGR对网络延迟极其敏感，跨机房部署基本等于自找麻烦。另外，MGR的流控机制在大事务场景下会疯狂限流，批量导入数据时能把人逼疯。我的建议是：除非你有明确的自动切换需求，否则别碰MGR。

MySQL Cluster（NDB）是另一条路。它用内存存储，写入吞吐极高，但数据量受内存限制，JOIN性能差，运维复杂度高。国内用NDB的团队不多，踩坑资料也少。除非你做电信级实时计费，否则没必要。

部署时几个硬细节：

第一，server_id绝对不能重复。MGR和传统复制都靠这个区分节点，重复了直接报错。

第二，binlog格式必须用ROW。MGR强制要求，传统复制也建议用ROW，避免函数和触发器的复制不一致。

第三，GTID打开。MGR依赖GTID做冲突检测和恢复，传统复制用GTID切换也方便得多。

第四，时间同步。NTP或者chrony必须配好，节点间时间偏差超过1秒，MGR可能直接踢人。

第五，网络。MGR节点间建议万兆内网，延迟控制在1ms以内。跨机房？先测网络抖动，超过5ms就别想了。

以MGR三节点为例，核心配置大概这样：

[mysqld] server_id=1 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-aaaa-aaaa-aaaa-aaaaaaaaaaaa" group_replication_start_on_boot=OFF group_replication_local_address="192.168.1.1:33061" group_replication_group_seeds="192.168.1.1:33061,192.168.1.2:33061,192.168.1.3:33061" group_replication_bootstrap_group=OFF 

三个节点都配好之后，第一个节点执行 SET GLOBAL group_replication_bootstrap_group=ON; 再 START GROUP_REPLICATION;，然后关掉bootstrap。剩下两个节点直接START GROUP_REPLICATION就加进去了。

验证集群状态用 SELECT * FROM performance_schema.replication_group_members;，三个节点都是ONLINE才算正常。

最后说个真实教训。某次帮朋友处理MGR故障，三个节点里两个同时重启，剩下那个因为失去多数派直接变成只读。业务侧没做重试，所有写入全报错。后来加了ProxySQL做前端路由，检测到主节点不可写就切到备用集群。MGR本身不解决应用层的高可用，别把锅全甩给数据库。

选型没有银弹。小团队用MHA加半同步复制，稳当省心。大厂有专职DBA团队，MGR或者自研方案都可以折腾。关键是先搞清楚自己的故障恢复目标——RTO和RPO定下来，方案自然就清晰了。