【整理】组建 MySQL 集群的几种方案

金官丁 在 知乎 上的回答。 

组建 mysql 集群的几种方案 

lvs+keepalived+mysql（有脑裂问题？但似乎很多人推荐这个）

drbd+heartbeat+mysql（有一台机器空余？heartbeat 切换时间较长？有脑裂问题？）

mysql proxy（不够成熟与稳定？使用了 lua？是不是用了他做分表则可以不用更改客户端逻辑？）

mysql cluster （社区版不支持 innodb 引擎？商用案例不足？）

mysql + mha （如果配上异步复制，似乎是不错的选择，又和问题？）

mysql + mmm （似乎反映有很多问题，未实践过，谁能给个说法）

回答： 

不管哪种方案都是有其场景限制或说规模限制，以及优缺点的。 

首先反对大家做读写分离，关于这方面的原因解释太多次数（增加技术复杂度、可能导致读到落后的数据等），只说一点：99.8% 的业务场景没有必要做读写分离，只要做好数据库设计优化和配置合适正确的主机即可；

keepalived+mysql -- 确实有脑裂的问题，还无法做到准确判断 mysqld 是否 hang 的情况；

drbd+heartbeat+mysql -- 同样有脑裂的问题，还无法做到准确判断 mysqld 是否 hang 的情况，且 drdb 是不需要的，增加反而会出问题；

mysql proxy -- 不错的项目，可惜官方半途夭折了，不建议用，无法高可用，是一个写分离；

mysql cluster -- 社区版本不支持 ndb 是错误的言论，商用案例确实不多，主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高；

mysql + mha -- 可以解决脑裂的问题，需要的 ip 多，小集群是可以的，但是管理大的就麻烦，其次 mysql + mmm 的话且坑很多，有 mha就没必要采用 mmm。

建议： 

若是双主复制的模式，不用做数据拆分，那么就可以选择 mha 或 keepalive 或 heartbeat；

若是双主复制，还做了数据的拆分，则可以考虑采用 cobar；

若是双主复制+slave，还做了数据的拆分，需要读写分类，可以考虑 amoeba；

上述所有的内容都要依据公司内部的业务场景、数据量、访问量、并发量、高可用的要求、dba 人群的数量等 综合权衡。