MySQL高可用入门：告别单点故障，轻松实现自动容灾
|
去年秋天，我帮一家电商公司搭建MySQL高可用集群——他们之前用单库跑订单系统，凌晨三点服务器宕机，直接损失六位数订单，老板拍桌子要求“必须24小时不能停”。当时我选了MySQL Group Replication（MGR），这玩意儿是MySQL官方出的新技术，比老牌的MHA方案更省事儿——不需要写复杂的脚本，配置好参数就能自动选主，数据同步用Paxos协议，比异步复制靠谱多了。
文章配图，仅供参考 测试阶段我故意搞破坏：拔掉主库网线，5秒内其他节点自动选了个新主，应用层连接池自动重连，订单系统根本没感知到异常——这比之前用MHA时，主库挂了要手动切流量快多了。不过MGR也有坑——节点数量必须是奇数（3/5/7），偶数个节点会分裂成两个小集群，去年双十一前夜，他们运维误加了台节点，结果集群直接分裂，订单数据在两个库里各自写入，差点出大事故。MGR的“自动容灾”不是万能的——它只管数据库层，网络分区、磁盘损坏这些硬件问题，还得靠外部监控。我见过最离谱的案例：某公司用MGR集群，主库所在机房的光纤被施工队挖断，其他节点虽然能选主，但应用层连接池因为DNS缓存没更新，还是往老IP发请求，等运维发现时，数据库已经积压了半小时的写入请求，恢复时得手动合并数据，差点没赶上月底结账。 新技术的好处是“开箱即用”——MGR的配置文件就20行，比MHA的100多行脚本简单多了，但简单不等于没门槛——比如“group_replication_group_name”这个参数，必须用UUID生成，不能随便写，我之前见过有人直接填“123456”，结果集群启动失败，日志里全是“Invalid group name”的报错，查了半天才发现是参数值不对。 MGR的监控得用Performance Schema——里面有个“replication_group_members”表，能实时看节点状态。我教运维写了个Shell脚本，每分钟查一次这个表，如果发现“MEMBER_STATE”不是“ONLINE”，就发企业微信报警。去年双十二，这个脚本救了他们一次：凌晨两点，一个节点突然变成“UNREACHABLE”，运维收到报警后，10分钟内就定位到是交换机端口故障，换了个端口，集群自动恢复，订单系统没受影响。 不过MGR也有局限——它不支持多主写入，只能单主写，其他节点只读。如果业务需要多主写入（比如用户数据分散在不同库），得用Galera Cluster或者MySQL NDB Cluster，但这些方案更复杂，配置文件能写满一页A4纸。我建议零基础的同学先玩透MGR——毕竟“自动选主+数据强一致”已经能解决80%的高可用需求，剩下的20%等业务规模上去了再考虑也不迟。 下一步该干啥？去官网下载MySQL 8.0（MGR在5.7.17之后才支持，但8.0更稳定），找个测试环境装三台虚拟机，按官方文档配MGR集群——记得把“group_replication_bootstrap_group”参数只在第一个节点设为ON，其他节点设为OFF，否则集群会分裂。配好后用sysbench压测，故意kill掉主库进程，看其他节点能不能自动选主，应用层能不能无缝切换——亲自动手试一遍，比看十篇教程都有用。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
