基于MyCat的MySQL高可用读写分离集群

这套资料的主题很明确：用 MyCat 做 MySQL 的读写分离，再用 HAProxy + Keepalived 把 MyCat 这一层也做成高可用。它不是单点工具的演示，而是一条完整的链路——MySQL 主从复制负责数据同步，MyCat 负责 SQL 路由与读写分离，HAProxy 负责对 MyCat 做负载均衡，Keepalived 负责 VIP 漂移。四层叠起来，才算一个能拿去对照的集群方案。

这套资料的技术栈边界

先把涉及的角色理清楚，避免当成"装个中间件就完事"。

• MySQL 主从复制：binlog 格式、server-id、复制账号、SHOW SLAVE STATUS里的关键字段，是后面一切的前提。
• MyCat：逻辑库/逻辑表、schema.xml 与 server.xml 的分工、读写分离的拦截规则、心跳检测。
• HAProxy：backend/frontend 配置、对 MyCat 端口的健康检查、负载均衡算法选择。
• Keepalived：VRRP 协议、VIP 漂移、与 HAProxy 的配合方式。

可以看出，这套内容的跨度偏运维与中间件配置，而不是应用层开发。如果你的日常是写业务代码，它能帮你把"数据库那一侧到底发生了什么"补上；如果你本来就在做部署和运维，它给出的是一条可以逐步验证的搭建顺序。

项目结构与配置的层次关系

这类集群的难点不在单个组件的安装，而在配置之间的对应关系。MyCat 里定义的写库和读库，必须和 MySQL 主从的实际角色一一对上；HAProxy 里 backend 指向的 MyCat 节点，必须和 Keepalived 管理的 VIP 协同工作。任何一层写错，表现出来都是"连上了但数据不对"或"主库挂了读库没顶上"这类模糊现象。

资料把 Linux 下 MySQL 安装、主从配置、MyCat 读写分离、HAProxy+Keepalived 高可用按顺序铺开，这个顺序本身就是排查思路：先确认主从同步正常，再确认 MyCat 路由正确，最后才谈 MyCat 自身的容错。倒过来做，出问题时分不清是哪一层。

可复用的部分在哪里

值得单独拎出来复用的，是几个可以直接迁移的配置骨架：MyCat 的 schema 与读写分离规则、HAProxy 针对 MyCat 健康检查的参数、Keepalived 的 VRRP 实例定义。这些配置换个 IP、换台机器就能用到自己的测试环境里，比看一遍视频更实在。

另外，主从复制那一段的验证方法（写入主库、观察从库、检查延迟）也是通用的排障动作，不限于这套方案。把它固化成自己的检查清单，后面遇到复制中断、延迟飙升时能省不少时间。

建议的使用方式

不要只顺着看。比较有效的做法是：准备三到四台虚拟机或容器，按章节把环境搭起来，每搭完一层就用客户端连一次、写一次、读一次，确认行为符合预期再往下走。特别是主从切换和 MyCat 节点宕机这两个场景，自己手动停掉进程看 VIP 和路由怎么变，比记住结论有用得多。

配套的章节笔记适合在动手之后回看，用来对齐自己踩过的坑和资料里的配置差异。这套内容的价值在于它给了一条完整、可验证的搭建路径，跟着走一遍，MySQL 读写分离和高可用这一层的结构就立起来了。