组建MySQL集群的几种方案

　

组建MySQL集群的几种方案
LVS+Keepalived+MySQL（有脑裂问题？但彷佛不少人推荐这个）
DRBD+Heartbeat+MySQL（有一台机器空余？Heartbeat切换时间较长？有脑裂问题？）
MySQL Proxy（不够成熟与稳定？使用了Lua？是否是用了他作分表则能够不用更改客户端逻辑？）
MySQL Cluster （社区版不支持INNODB引擎？商用案例不足？）
MySQL + MHA （若是配上异步复制，彷佛是不错的选择，又和问题？）
MySQL + MMM （彷佛反映有不少问题，未实践过，谁能给个说法）

回答：

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

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人群的数量等 综合权衡，如果须要能够联系我：jinguanding# http://hotpu.cn

 

 

 

有不少架构师,仍是比较推崇使用基于DRBD架构的.　

若是是基于复制的 shared-nothing 架构，不作读写分离，多节点同时写入，一定会冲突啊！

是否是笔误呢？题主问题是MySQL Cluster 社区版本不支持InnoDB引擎，不是NDB，NDB引擎固然会支持了。

 

 

题主对mysq的高可用及集群方式了解比较充分。应该说按照实际商用的场景来设计数据库集群架构，这样才是合理的。若是你追求完美的高可用，避免任何的单点故障，能够在主从、主主同步的基础上配合keepalived或是heartbeat，这二者作故障切换都很好用。高性能上，与其期望一套数据库后端服务搞定全部业务，不如考虑不一样业务的在不一样服务器资源上的sharding，但其管理复杂度一定会增长，看你怎么权衡管理性和性能方面。关于可扩展性，mysql代理（如阿里的amoeba）+mysql一主多从能够考虑。总之没有最好的方案，只有最合适的！

 

 

 

做者：jhh
连接：https://www.zhihu.com/question/21307639/answer/123316479
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

先介绍几种方案

• 主从复制，包括一拖一的主从和一拖多的主从

高可用性 ：比较高

高可扩展性 ：无

高一致性 ：比较高

延迟性 ：比较小

并发性 ：无

事务性 ：无

吞吐率 ：比较高

数据丢失 ：不丢失

可切换 ：能够切换

• 环形复制,包括两个节点和多个节点造成的环形

高可用性 ：比较高

高可扩展性 ：无

高一致性 ：比较高

延迟性 ：比较小

并发性 ：无

事务性 ：无

吞吐率 ：比较高

数据丢失 ：不丢失

可切换 ：能够切换

• 2PC：

高可用性 ： 很高

高可扩展性 ： 可扩展，不能大规模扩展，也无需大规模扩展

高一致性 ： 比较高

延迟性 ： 比较大

并发性 ： 比较小

事务性 ： 有

吞吐率 ： 比较小

数据丢失 ： 不丢失

可切换 ： 无关

• Paxos：元数据的高可用，并发度不高

高可用性 ： 很高

高可扩展性 ： 无关 可扩展，不能大规模扩展，也无需大规模扩展

高一致性 ： 很高

延迟性 ： 比较大

并发性 ： 比较小

事务性 ： 有

吞吐率 ： 比较小

数据丢失 ： 不丢失

可切换 ： 无关

以上纯属我的理解，若有异议，也是没问题的；

另外按照master是否服务具体业务来分分布式能够分为两类：

1. master管理系统，而且全部请求经过master，很明显master存在性能瓶颈
2. master管理系统，实际请求不经过master，请求分散均匀了

确定选方案2

基于这些方案的特色，如何设计一个牛逼滴分布式系统 ？

这里的牛逼包括

• 可大规模扩展：要求像hadoop那样，至少几百条台没问题
• 高可用：master须要高可用，节点也须要高可用，也就是说任何一个组件的一个实例或者部分实例挂了，都不会影响整个系统
• 高并发：普通机器单节点至少要支持几千的并发度吧，若是扩展解决了，整个系统的并发其实也扩展的
• 数据一致性:分布式系统，一致性可难了，尽可能保证吧，好比主从同步实现一致 ，或者使用两阶段2pc同时写多个节点，或者使用像paxos一致性协议算法实现哈
• 事务性：分布式系统，绝对的事务很难吧，哎，咱们就用2pc，3pc吧，尽可能保证哈
• 自动切换 ： 首先你得想自动切换的条件如何呢？ 好比主从同步，主挂了，我能够自动切换到从，但是若是从数据和主不一样步，可是业务要求很高，不容许这种状况出现，那也只好停服维护啦。

好了 你能够开始喷了 ， 怎么可能。

paxos一致性协议，可用性很高，一致性很高，事务性很不错 ， 那么涉及到各类服务均可以用他，很是好。

master和metadata元数据采用paxos一致性协议，全部节点也采用paxos一致性协议 ， 客户端保持这些信息。架构以下所示 ，master, metadata, node 都实现了paxos协议，也即经过paxos接口访问

分布式数据库就是一个例子，貌似目前流行的数据库都尚未支持paxos协议的，有谁能够开发下。节点采用paxos的话，有个问题没想清楚，paxos如何sql结合使用？另外节点的性能会受一点影响。下降一点要求吧，节点采用主主复制，或者环形复制吧。master检查节点存活，而且作切换，通知客户端。

架构以下所示 ，master, metadata,实现了paxos协议，也即经过paxos接口访问;node的各个节点是复制关系，服务节点挂掉的时候，须要master检测，而且作切换处理。

 

若是是分布式系统，好比文件系统，或者本身开发的系统， 那节点能够考虑用paxos协议哦。 每一个节点采用3个实例，或者你有资源，采用5个实例。

分布式数据库的sql实现

也是一个难点，即一个复杂的sql，如何实现？

 

•使用分库分表的思想实现数据存储
•使用mapred的思想实现sql计算


•将输入sql通过词法，语法，语义分析，集合表结构信息和数据分布信息，生成包含多个阶段(简称stage)的执行计划，这些阶段具备必定的依赖关系，造成多输入单输出的任务树；
•每一个阶段包括两种sql，称为mapsql和redsql，另外每一个阶段包括三个操做，map，数据洗牌和red；map和red分别执行mapsql和redsql；

子句的处理逻辑和处理顺序 ：

1.union：分解每一个子句，单独解析，造成平行关系
2.from：选择表，能够是选择多张表，也但是join的状况
3.join：from中若是包含join，就要考虑join的各类问题
4.where：单表，多表，join以后的where过滤条件
5.group：分组
6.select：选择的列
7.distinct：去掉重复的行
8.having：聚合以后的过滤
9.order：将结果排序
10.limit offset：获取最终结果的某些记录
11.子查询：遇到子查询独立解析，跟上层创建依赖关系

链接，包括内链接，左链接，右链接，半链接，外链接

以以下sql为例：

某一注册时间范围内的用户的全部登陆信息

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id and t1.u_reg_dt>=? and t1.u_reg_dt<=?)

生成的执行计划为：

因为是join，全部的表都要进行查询操做，而且为每张表打上本身的标签，具体实施的时候能够加个表名字字段，在全部存储节点上执行

select u_id,u_name from tab_user_info t where u_reg_dt>=? and t1.u_reg_dt<=?

select u_id, login_product from tab_login_info t

执行完成以后，这种状况下因为须要按照u_id进行数据洗牌，考虑到u_id的惟一值比较多，因此各个存储节点上须要按照u_id进行划分，

例若有N个计算节点，那么按照（最大u_id-最小u_id）/N平均划分，将不一样存储节点上的同一范围的u_id，划分到同一个计算节点上

而后在计算节点上执行以下操做

select t1.u_id,t1.u_name,t2.login_product

from tab_user_info t1 join tab_login_info t2

on (t1.u_id=t2.u_id)

关于分布式sql如何实现的问题，有不少未尽事宜。有兴趣的能够相互讨论。欢迎切磋

 

 

 

 

几点补充：

1.对于须要严格保证强一致的场合来讲，至少在 MySQL 5.7 以前，DRBD 仍是有意义的。5.7 听说能实现真同步复制，若真能实现，就再也不须要 DRBD 了。

2.网络分区时的脑裂问题必须避免，应使用基于多数派的选举算法来推选 Master。方案不少，好比用 ZooKeeper、etcd、Consul 等进行服务选举，推选出 Master。

3.MHA 没深刻了解过，但印象里其 Master（Arbiter）节点貌似有单点问题？没记错的话此节点用于完成 MySQL 的主节点选举工做，它本身不 HA 仍是有隐患。

 

 

 

MySQL大型分布式集群一、主要解决针对大型网站架构中持久化部分中，大量数据存储以及高并发访问所带来是数据读写问题。分布式是将一个业务拆分为多个子业务，部署在不一样的服务器上。集群是同一个业务，部署在多个服务器上。

二、着重对数据切分作了细致丰富的讲解，从数据切分的原理出发，一步一步深刻理解数据的切分，经过深刻理解各类切分策略来设计和优化咱们的系统。这部分中咱们还用到了数据库中间件和客户端组件来进行数据的切分，让广大网友可以对数据的切分从理论到实战都会有一个质的飞跃。

没有人提到Atlas Atlas是由 Qihoo 360, Web平台部基础架构团队开发维护的一个基于MySQL协议的数据中间层项目。它是在mysql-proxy 0.8.2版本的基础上，对其进行了优化，增长了一些新的功能特性。360内部使用Atlas运行的mysql业务，天天承载的读写请求数达几十亿条。