组建MySQL集群的几种方案,优劣与讨论.docxVIP

组建 MySQL 集群的几种方案 LVS+Keepalived+MySQL （有脑裂问题？但似乎很多人推荐这个） DRBD+Heartbeat+MySQL （有一台机器空余？ Heartbeat 切换时间较长？有脑裂问题？） MySQL Proxy （不够成熟与稳定？使用了Lua ？是不是用了他做分表则可以不用更改客户 端逻辑？） MySQL Cluster （社区版不支持INNODB 引擎？商用案例不足？稳定性欠佳？或者还有其他问题？又或者听说现在发展不错？） MySQL + MHA （如果配上异步复制，似乎是不错的选择，又和问题？） MySQL + MMM （似乎反映有很多问题，未实践过，谁能给个说法） 淘宝的Cola( 似乎现在停止开发了？)？变形虫Amoeba （事务支持？） 或者，其他方案？ 回答 1 ： 不管哪种方案都是有其场景限制 或说 规模限制，以及优缺点的。 首先反对大家做读写分离，关于这方面的原因解释太多次数（增加技术复杂度、可能导致读到落后的数据等），只说一点：99.8% 的业务场景没有必要做读写分离，只要做好数据库设计优化 和配置合适正确的主机即可。 Keepalived+MySQL --确实有脑裂的问题，还无法做到准确判断mysqld 是否 HANG 的情况； DRBD+Heartbeat+MySQL --同样有脑裂的问题，还无法做到准确判断mysqld 是否HANG 的情况，且DRDB 是不需要的，增加反而会出问题； MySQL Proxy -- 不错的项目，可惜官方半途夭折了，不建议用，无法高可用，是一个写分离； MySQL Cluster -- 社区版本不支持NDB 是错误的言论，商用案例确实不多，主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高； 5.MySQL + MHA -- 可以解决脑裂的问题，需要的IP 多，小集群是可以的，但是管理大的就麻烦，其次MySQL + MMM 的话且坑很多，有MHA 就没必要采用MMM 建议： 1.若是双主复制的模式，不用做数据拆分，那么就可以选择 MHA 或 Keepalive 或heartbeat 若是双主复制，还做了数据的拆分，则可以考虑采用Cobar 若是双主复制，还做了数据的拆分，则可以考虑采用Cobar ； 若是双主复制+Slave ，还做了数据的拆分，需要读写分类，可以考虑Amoeba ； 上述所有的内容都要依据公司内部的业务场景、数据量、访问量、并发量、高可用的要求、 DBA 人群的数量等 综合权衡 这是我在 知乎 上的一个问题，就一人回答了下，搬上 CU 来讨论讨论，本人之前开发人员， 对 MySQL 不太熟，现国内『某省运营商』希望出个分布式 MySQL 的方案，就方案的那种， 结果摊到小弟头上，望大神指点迷津。