Chinaunix

标题: 组建MySQL集群的几种方案，优劣与讨论。 [打印本页]
作者: alexsunmiu    时间: 2013-08-08 09:41
标题: 组建MySQL集群的几种方案，优劣与讨论。
组建MySQL集群的几种方案

LVS+Keepalived+MySQL（有脑裂问题？但似乎很多人推荐这个）
DRBD+Heartbeat+MySQL（有一台机器空余？Heartbeat切换时间较长？有脑裂问题？）
MySQL Proxy（不够成熟与稳定？使用了Lua？是不是用了他做分表则可以不用更改客户端逻辑？）
MySQL Cluster （社区版不支持INNODB引擎？商用案例不足？稳定性欠佳？或者还有其他问题？又或者听说现在发展不错？）
MySQL + MHA （如果配上异步复制，似乎是不错的选择，又和问题？）
MySQL + MMM （似乎反映有很多问题，未实践过，谁能给个说法）
淘宝的Cola(似乎现在停止开发了？)？变形虫Amoeba（事务支持？）
或者，其他方案？


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

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

2.Keepalived+MySQL --确实有脑裂的问题，还无法做到准确判断mysqld是否HANG的情况；

3.DRBD+Heartbeat+MySQL --同样有脑裂的问题，还无法做到准确判断mysqld是否HANG的情况，且DRDB是不需要的，增加反而会出问题；

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

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

5.MySQL + MHA -- 可以解决脑裂的问题，需要的IP多，小集群是可以的，但是管理大的就麻烦，其次MySQL + MMM 的话且坑很多，有MHA就没必要采用MMM


建议：
1.若是双主复制的模式，不用做数据拆分，那么就可以选择MHA或 Keepalive 或 heartbeat
2.若是双主复制，还做了数据的拆分，则可以考虑采用Cobar；
3.若是双主复制+Slave，还做了数据的拆分，需要读写分类，可以考虑Amoeba；

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


这是我在 知乎 上的一个问题，就一人回答了下，搬上CU来讨论讨论，本人之前开发人员，对MySQL不太熟，现国内『某省运营商』希望出个分布式MySQL的方案，就方案的那种，结果摊到小弟头上，望大神指点迷津。

作者: alexsunmiu    时间: 2013-08-08 14:50
谢老大置顶~~~不过貌似，这坑水好深。。。
作者: expert1    时间: 2013-08-08 16:40
此贴必顶，学习。
作者: alexsunmiu    时间: 2013-08-08 17:27
感觉八仙过海各显神通似得~~~

不晓得有没有啥比较权威的，银弹？
作者: seesea2517    时间: 2013-08-09 09:59
大场面！希望能听到内行的详解。
作者: Mylib    时间: 2013-08-09 10:54
希望看到具体的方案教程
作者: 虎皮尖椒    时间: 2013-08-09 11:44
本帖最后由 虎皮尖椒 于 2013-08-09 11:59 编辑

mysql不是自己就带个主从读写分离的方案不？

你说的几个方案我都不了解，就像第一个lvs,我感觉lvs的作用不过是分发mysql负载，lvs后面的mysql地位是对等的，但是，mysql应用后面的数据文件内容需要彼此之间同步啊(这时候lvs一点忙也帮不上)。
作者: action08    时间: 2013-08-10 12:40
感觉给的实际细节太少了，个人也缺少相关的场景经验，所以没分量也说不上话呀
作者: lastexile    时间: 2013-08-11 00:47
此贴必收藏，等高人
作者: alexsunmiu    时间: 2013-08-13 15:06
目前 某运营商旗下有一款面向广东的应用想扩展至全国业务，也想着跟阿里系凑热闹搞去IOE。。。找了我们公司做评估~~~

小弟也是菜鸟~~~请大神给出银弹。
作者: gghandsome    时间: 2013-08-14 09:32
Amoeba一直在用，缺点事务不支持，无存储过程，分表后数据排序不正确。特点分库后查询速度明显有提升。
mysql cluster 测试过，效率很不错，尤其是写入速度在多机时很有优势。缺点同样不支持事务，服务器磁盘的容量必须按最少的磁盘容量计算，因为数据平分在服务器上，磁盘最小的服务器满后整个群集不可写入。

数据库技术研究，欢迎邮件交流6442642@163.com
作者: 5iwww    时间: 2013-08-14 16:46
LZ 你先搞清楚每种设置的用途再把他们放在一起， 感觉你把所有能知道的mysql单台以上的工作方法都写里面了，有些功能目的都不一样，怎么比？
作者: caabcal    时间: 2013-08-14 23:37

MySQL Cluster 跟怎样的业务场景要求有关系？



alexsunmiu 发表于 2013-08-08 09:41
组建MySQL集群的几种方案

LVS+Keepalived+MySQL（有脑裂问题？但似乎很多人推荐这个）

4.MySQL Cluster -- 社区版本不支持NDB是错误的言论，商用案例确实不多，主要是跟其业务场景要求有关系、这几年发展有点乱不过现在已经上正规了、对网络要求高；
作者: imisskiss    时间: 2013-08-16 22:08
学习学习   在以后遇到中使用
作者: 开着Q7去西藏    时间: 2013-08-17 11:09
吭吭哧哧能把主从搞了，到现在没接触过实际的大数据场景哎
作者: markgeng    时间: 2013-08-23 11:23
1.MariaDB Galera Cluster
2.Heartbeat_MariaDB Galera Master/Master Replication
3.Heartbeat_Haproxy_MariaDB Galera Master/Master Replication
作者: luyee2010    时间: 2014-10-09 23:58
这条不懂：

1. 首先反对大家做读写分离，关于这方面的原因解释太多次数（增加技术复杂度、可能导致读到落后的数据等），只说一点：99.8%的业务场景没有必要做读写分离，只要做好数据库设计优化 和配置合适正确的主机即可。
作者: chengchow    时间: 2014-10-10 14:17
本帖最后由 chengchow 于 2014-10-10 14:20 编辑

很少有人会将你列出来的应用都做了，所以你看到的这个回答应该是网上搜索出来总结的，不一定会正确
keepalived是通过虚拟IP实现高可用，这种情况同heartbeat通过心跳线判断对方是否存活不同，应该不存在脑裂问题
如果你不用到读写分离keepalived+lvs+mysql确实是不错的解决方案，
不过我有个疑问？你不做读写分离，如何让3台以上数据库的数据同步，而又能保证性能
考虑读写分离
keepalived+HAproxy+mysql应该是可以的
... ...
数据库集群应用我也是菜鸟，坐等高手来结贴
作者: ruochen    时间: 2014-10-17 11:25
挖了个大坑


MySQL根据应用场景和应用规模有各种分法，这也是MySQL灵活和火的原因之一
每个团队在MySLQ都可以玩出很多东西

上面列出的是很多分享出来的一些解法，其实还有很多一直没有分享出来的解法
比如你举例出来的hang探测问题，我一般直接做个库，一张表一条记录，直接做update，在规定的时间看返回值来判断
作者: ruochen    时间: 2014-10-17 11:29
大规模的MySQL集群，基本是靠中间件了，也有很多中间件的案例没有分享出来

MHA
PXC
KeepaLived
自己开发中间件

以上的解法更普遍和推荐
作者: lyhabc    时间: 2015-03-31 20:49
我们用的第一种
1.若是双主复制的模式，不用做数据拆分，那么就可以选择MHA或 Keepalive 或 heartbeat和HAProxy
作者: lyhabc    时间: 2015-03-31 22:20
本帖最后由 lyhabc 于 2015-03-31 22:21 编辑

LVS+Keepalived+MySQL（有脑裂问题？但似乎很多人推荐这个）
DRBD+Heartbeat+MySQL（有一台机器空余？Heartbeat切换时间较长？有脑裂问题？）


2.Keepalived+MySQL --确实有脑裂的问题，还无法做到准确判断mysqld是否HANG的情况；

3.DRBD+Heartbeat+MySQL --同样有脑裂的问题，

5.MySQL + MHA -- 可以解决脑裂的问题，

造成脑裂的主要问题其实是缺少仲裁，没有选举，没有判断
作者: doway    时间: 2015-04-22 10:24
最近想研究mysql的集群部署方案，也是给运营商的，收藏，等专家给一些建议解答
作者: zkernel    时间: 2016-01-22 13:08
keepalived 我暂且还没遇到过脑裂问题

Heartbeat 倒是分分种就脑裂


怎么没提起amoeba呢？
作者: raygts    时间: 2016-02-01 17:57
我也在为这个烦着，我说说我的见解
首先 lvs + keepalived 做Master +Ｍａｓｔｅｒ其实我比较不赞同这种方法，我假设环境：　InnoDB存储引擎　ｂｉｎｌｏｇ做ｒｏｗ格式＋半同步，innodb_flush_log_at_trx_commit与sync_binlog 均为1 两台服务器A与B（MySQL 5.6.28版本）
现在A是ａｃｔｉｖｅ机器，
现在A机器上有若干事务进行中，每个事务有若干个save point 现在A机器出现硬件故障崩溃了。A机器重启后必定会进行recover跟undo，而现在B机器的是否会跟着做呢？
如果换成MyISAM 存储引擎存在大量写数据又如何？
我以前曾经遇过一个情景是这样的：
有很多事务在A机器进行，特别是大量insert into语句（primary key全部是auto increment），A服务器现在硬件故障突然崩溃了，现在切换到B机器业务继续发生也有大量的insert update等发生。修复好A机器后发生了这样一件事：B机器进行update的时候A机器的slave stop了，说找不到那个primary key。个人猜是A机器重启后对之前的事务用了的数据全部回滚了，而PK不再重复使用，所以导致A机器与B机器数据不一致。

对于DRDB + Corosync +Pacemaker 做高可用又是否还存在脑裂问题？不过貌似对MyISAM没任何意义，MyISAM无法自行修复，这个是Oracle官网推荐配置。
MHA貌似可靠性比较高不过实现起来比较复杂，我没测试过不知道对于大量写数据是否存在问题，也希望论坛上的高手能详细说说它的原理
作者: raygts    时间: 2016-02-01 17:57
本帖最后由 raygts 于 2016-02-01 17:58 编辑

我也在为这个烦着，我说说我的见解
首先 lvs + keepalived 做Master +Ｍａｓｔｅｒ其实我比较不赞同这种方法，我假设环境：　InnoDB存储引擎　ｂｉｎｌｏｇ做ｒｏｗ格式＋半同步，innodb_flush_log_at_trx_commit与sync_binlog 均为1 两台服务器A与B（MySQL 5.6.28版本）
现在A是ａｃｔｉｖｅ机器，
现在A机器上有若干事务进行中，每个事务有若干个save point 现在A机器出现硬件故障崩溃了。A机器重启后必定会进行recover跟undo，而现在B机器的是否会跟着做呢？
如果换成MyISAM 存储引擎存在大量写数据又如何？
我以前曾经遇过一个情景是这样的：
有很多事务在A机器进行，特别是大量insert into语句（primary key全部是auto increment），A服务器现在硬件故障突然崩溃了，现在切换到B机器业务继续发生也有大量的insert update等发生。修复好A机器后发生了这样一件事：B机器进行update的时候A机器的slave stop了，说找不到那个primary key。个人猜是A机器重启后对之前的事务的数据全部回滚了，而PK不再重复使用，所以导致A机器与B机器数据不一致。

对于DRDB + Corosync +Pacemaker 做高可用又是否还存在脑裂问题？不过貌似对MyISAM没任何意义，MyISAM无法自行修复，这个是Oracle官网推荐配置。
MHA貌似可靠性比较高不过实现起来比较复杂，我没测试过不知道对于大量写数据是否存在问题，也希望论坛上的高手能详细说说它的原理



欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2