mysql集群简介

集群的好处

高可用性&＃xff1a;故障检测及迁移&＃xff0c;多节点备份。

可伸缩性&＃xff1a;新增数据库节点便利&＃xff0c;方便扩容。

负载均衡&＃xff1a;切换某服务访问某节点&＃xff0c;分摊单个节点的数据库压力。

集群要考虑的风险

网络分裂&＃xff1a;群集还可能由于网络故障而拆分为多个部分&＃xff0c;每部分内的节点相互连接&＃xff0c;但各部分之间的节点失去连接。

脑裂&＃xff1a;导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致&＃xff0c;并且无法修复&＃xff0c;例如当两个数据库节点独立更新同一表上的同一行时。

&＃64;[toc]

一&＃xff0c;mysql原厂出品

1&＃xff0c;MySQL Replication

mysql复制&＃xff08;MySQL Replication&＃xff09;&＃xff0c;是mysql自带的功能。

原理简介&＃xff1a;

主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令&＃xff0c;那么在从库同样的执行一遍&＃xff0c;从而达到主从复制的效果。在这个过程中&＃xff0c;master对数据的写操作记入二进制日志文件中(binlog)&＃xff0c;生成一个 log dump 线程&＃xff0c;用来给从库的 i/o线程传binlog。而从库的i/o线程去请求主库的binlog&＃xff0c;并将得到的binlog日志写到中继日志&＃xff08;relaylog&＃xff09;中&＃xff0c;从库的sql线程&＃xff0c;会读取relaylog文件中的日志&＃xff0c;并解析成具体操作&＃xff0c;通过主从的操作一致&＃xff0c;而达到最终数据一致。

技术图片

MySQL Replication一主多从的结构&＃xff0c;主要目的是实现数据的多点备份&＃xff08;没有故障自动转移和负载均衡&＃xff09;。相比于单个的mysql&＃xff0c;一主多从下的优势如下&＃xff1a;

如果让后台读操作连接从数据库&＃xff0c;让写操作连接主数据库&＃xff0c;能起到读写分离的作用&＃xff0c;这个时候多个从数据库可以做负载均衡。

可以在某个从数据库中暂时中断复制进程&＃xff0c;来备份数据&＃xff0c;从而不影响主数据的对外服务&＃xff08;如果在master上执行backup&＃xff0c;需要让master处于readonly状态&＃xff0c;这也意味这所有的write请求需要阻塞&＃xff09;。

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

主从复制是mysql自带的&＃xff0c;无需借助第三方。

数据被删除&＃xff0c;可以从binlog日志中恢复。

配置较为简单方便。

其劣势为&＃xff1a;

从库要从binlog获取数据并重放&＃xff0c;这肯定与主库写入数据存在时间延迟&＃xff0c;因此从库的数据总是要滞后主库。

对主库与从库之间的网络延迟要求较高&＃xff0c;若网络延迟太高&＃xff0c;将加重上述的滞后&＃xff0c;造成最终数据的不一致。

单一的主节点挂了&＃xff0c;将不能对外提供写服务。

2&＃xff0c;MySQL Fabirc

mysql织物&＃xff08;MySQL Fabirc&＃xff09;&＃xff0c;是mysql官方提供的。

这是在MySQL Replication的基础上&＃xff0c;增加了故障检测与转移&＃xff0c;自动数据分片功能。不过依旧是一主多从的结构&＃xff0c;MySQL Fabirc只有一个主节点&＃xff0c;区别是当该主节点挂了以后&＃xff0c;会从从节点中选择一个来当主节点。

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

mysql官方提供的工具&＃xff0c;无需第三方插件。

数据被删除&＃xff0c;可以从binlog日志中恢复。

主节点挂了以后&＃xff0c;能够自动从从节点中选择一个来当主节点&＃xff0c;不影响持续对外提供写服务。

其劣势为&＃xff1a;

从库要从binlog获取数据并重放&＃xff0c;这肯定与主库写入数据存在时间延迟&＃xff0c;因此从库的数据总是要滞后主库。

对主库与从库之间的网络延迟要求较高&＃xff0c;若网络延迟太高&＃xff0c;将加重上述的滞后&＃xff0c;造成最终数据的不一致。

2014年5月推出的产品&＃xff0c;数据库资历较浅&＃xff0c;应用案例不多&＃xff0c;网上各种资料相对较少。

事务及查询只支持在同一个分片内&＃xff0c;事务中更新的数据不能跨分片&＃xff0c;查询语句返回的数据也不能跨分片。

节点故障恢复30秒或更长&＃xff08;采用InnoDB存储引擎的都这样&＃xff09;。

3&＃xff0c;MySQL Cluster

mysql集群&＃xff08;MySQL Cluster&＃xff09;也是mysql官方提供的。

MySQL Cluster是多主多从结构的

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

mysql官方提供的工具&＃xff0c;无需第三方插件。

高可用性优秀&＃xff0c;99.999%的可用性&＃xff0c;可以自动切分数据&＃xff0c;能跨节点冗余数据&＃xff08;其数据集并不是存储某个特定的MySQL实例上&＃xff0c;而是被分布在多个Data Nodes中&＃xff0c;即一个table的数据可能被分散在多个物理节点上&＃xff0c;任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作&＃xff0c;都将在一组Data Nodes上同步&＃xff0c;以保证数据的一致性&＃xff09;。

可伸缩性优秀&＃xff0c;能自动切分数据&＃xff0c;方便数据库的水平拓展。

负载均衡优秀&＃xff0c;可同时用于读操作、写操作都都密集的应用&＃xff0c;也可以使用SQL和NOSQL接口访问数据。

多个主节点&＃xff0c;没有单点故障的问题&＃xff0c;节点故障恢复通常小于1秒。

其劣势为&＃xff1a;

架构模式和原理很复杂。

只能使用存储引擎 NDB &＃xff0c;与平常使用的InnoDB 有很多明显的差距。比如在事务&＃xff08;其事务隔离级别只支持Read Committed&＃xff0c;即一个事务在提交前&＃xff0c;查询不到在事务内所做的修改&＃xff09;&＃xff0c;外键&＃xff08;虽然最新的NDB 存储引擎已经支持外键&＃xff0c;但性能有问题&＃xff0c;因为外键所关联的记录可能在别的分片节点&＃xff09;&＃xff0c;表限制上的不同&＃xff0c;可能会导致日常开发出现意外。点击查看具体差距比较

作为分布式的数据库系统&＃xff0c;各个节点之间存在大量的数据通讯&＃xff0c;比如所有访问都是需要经过超过一个节点&＃xff08;至少有一个 SQL Node和一个 NDB Node&＃xff09;才能完成&＃xff0c;因此对节点之间的内部互联网络带宽要求高。

Data Node数据会被尽量放在内存中&＃xff0c;对内存要求大&＃xff0c;而且重启的时候&＃xff0c;数据节点将数据load到内存需要很长时间。

官方的三兄弟的区别对比如下图所示&＃xff1b;

技术图片

二&＃xff0c;mysql第三方优化

4&＃xff0c;MMM

MMM是在MySQL Replication的基础上&＃xff0c;对其进行优化。

MMM&＃xff08;Master Replication Manager for MySQL&＃xff09;是双主多从结构&＃xff0c;这是Google的开源项目&＃xff0c;使用Perl语言来对MySQL Replication做扩展&＃xff0c;提供一套支持双主故障切换和双主日常管理的脚本程序&＃xff0c;主要用来监控mysql主主复制并做失败转移。

技术图片

注意&＃xff1a;这里的双主节点&＃xff0c;虽然叫做双主复制&＃xff0c;但是业务上同一时刻只允许对一个主进行写入&＃xff0c;另一台备选主上提供部分读服务&＃xff0c;以加速在主主切换时刻备选主的预热。

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

自动的主主Failover切换&＃xff0c;一般3s以内切换备机。

多个从节点读的负载均衡。

其劣势为&＃xff1a;

无法完全保证数据的一致性。如主1挂了&＃xff0c;MMM monitor已经切换到主2上来了&＃xff0c;而若此时双主复制中&＃xff0c;主2数据落后于主1&＃xff08;即还未完全复制完毕&＃xff09;&＃xff0c;那么此时的主2已经成为主节点&＃xff0c;对外提供写服务&＃xff0c;从而导致数据不一。

由于是使用虚拟IP浮动技术&＃xff0c;类似Keepalived&＃xff0c;故RIP&＃xff08;真实IP&＃xff09;要和VIP&＃xff08;虚拟IP&＃xff09;在同一网段。如果是在不同网段也可以&＃xff0c;需要用到虚拟路由技术。但是绝对要在同一个IDC机房&＃xff0c;不可跨IDC机房组建集群。

5&＃xff0c;MHA

MHA是在MySQL Replication的基础上&＃xff0c;对其进行优化。

MHA&＃xff08;Master High Availability&＃xff09;是多主多从结构&＃xff0c;这是日本DeNA公司的youshimaton开发&＃xff0c;主要提供更多的主节点&＃xff0c;但是缺少VIP&＃xff08;虚拟IP&＃xff09;&＃xff0c;需要配合keepalived等一起使用。

要搭建MHA&＃xff0c;要求一个复制集群中必须最少有三台数据库服务器&＃xff0c;一主二从&＃xff0c;即一台充当master&＃xff0c;一台充当备用master&＃xff0c;另外一台充当从库。

技术图片

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

可以进行故障的自动检测和转移

具备自动数据补偿能力&＃xff0c;在主库异常崩溃时能够最大程度的保证数据的一致性。

其劣势为&＃xff1a;

MHA架构实现读写分离&＃xff0c;最佳实践是在应用开发设计时提前规划读写分离事宜&＃xff0c;在使用时设置两个连接池&＃xff0c;即读连接池与写连接池&＃xff0c;也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码&＃xff1b;

关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具&＃xff0c;只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可&＃xff0c;建议使用LVS

6&＃xff0c;Galera Cluster

Galera Cluster是由Codership开发的MySQL多主结构集群&＃xff0c;这些主节点互为其它节点的从节点。不同于MySQL原生的主从异步复制&＃xff0c;Galera采用的是多主同步复制&＃xff0c;并针对同步复制过程中&＃xff0c;会大概率出现的事务冲突和死锁进行优化&＃xff0c;就是复制不基于官方binlog而是Galera复制插件&＃xff0c;重写了wsrep api。

异步复制中&＃xff0c;主库将数据更新传播给从库后立即提交事务&＃xff0c;而不论从库是否成功读取或重放数据变化。这种情况下&＃xff0c;在主库事务提交后的短时间内&＃xff0c;主从库数据并不一致。

同步复制时&＃xff0c;主库的单个更新事务需要在所有从库上同步 更新。换句话说&＃xff0c;当主库提交事务时&＃xff0c;集群中所有节点的数据保持一致。

对于读操作&＃xff0c;从每个节点读取到的数据都是相同的。对于写操作&＃xff0c;当数据写入某一节点后&＃xff0c;集群会将其同步到其它节点。

技术图片

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

多主多活下&＃xff0c;可对任一节点进行读写操作&＃xff0c;就算某个节点挂了&＃xff0c;也不影响其它的节点的读写&＃xff0c;都不需要做故障切换操作&＃xff0c;也不会中断整个集群对外提供的服务。

拓展性优秀&＃xff0c;新增节点会自动拉取在线节点的数据&＃xff08;当有新节点加入时&＃xff0c;集群会选择出一个Donor Node为新节点提供数据&＃xff09;&＃xff0c;最终集群所有节点数据一致&＃xff0c;而不需要手动备份恢复。

其劣势为&＃xff1a;

能做到数据的强一致性&＃xff0c;毫无疑问&＃xff0c;也是以牺牲性能为代价。

三&＃xff0c;依托硬件配合

不同主机的数据同步不再依赖于MySQL的原生复制功能&＃xff0c;而是通过同步磁盘数据&＃xff0c;来保证数据的一致性。

然后处理故障的方式是借助Heartbeat&＃xff0c;它监控和管理各个节点间连接的网络&＃xff0c;并监控集群服务&＃xff0c;当节点出现故障或者服务不可用时&＃xff0c;自动在其他节点启动集群服务。

7&＃xff0c;heartbeat&＃43;SAN

SAN&＃xff1a;共享存储&＃xff0c;主库从库用的一个存储。SAN的概念是允许存储设施和解决器&＃xff08;服务器&＃xff09;之间建立直接的高速连接&＃xff0c;通过这种连接实现数据的集中式存储。

技术图片

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

保证数据的强一致性&＃xff1b;

与mysql解耦&＃xff0c;不会由于mysql的逻辑错误发生数据不一致的情况&＃xff1b;

其劣势为&＃xff1a;

SAN价格昂贵&＃xff1b;

8&＃xff0c;heartbeat&＃43;DRDB

DRDB&＃xff1a;这是linux内核板块实现的快级别的同步复制技术。通过各主机之间的网络&＃xff0c;复制对方磁盘的内容。当客户将数据写入本地磁盘时&＃xff0c;还会将数据发送到网络中另一台主机的磁盘上&＃xff0c;这样的本地主机(主节点)与远程主机(备节点)的数据即可以保证明时同步。

技术图片

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

相比于SAN储存网络&＃xff0c;价格低廉&＃xff1b;

保证数据的强一致性&＃xff1b;

与mysql解耦&＃xff0c;不会由于mysql的逻辑错误发生数据不一致的情况&＃xff1b;

其劣势为&＃xff1a;

对io性能影响较大&＃xff1b;

从库不提供读操作&＃xff1b;

四&＃xff0c;其它

9&＃xff0c;Zookeeper &＃43; proxy

Zookeeper使用分布式算法保证集群数据的一致性&＃xff0c;使用zookeeper可以有效的保证proxy的高可用性&＃xff0c;可以较好的避免网络分区现象的产生。

技术图片

就各个集群方案来说&＃xff0c;其优势为&＃xff1a;

扩展性较好&＃xff0c;可以扩展为大规模集群。

缺其劣势为&＃xff1a;

搭建Zookeeper 集群&＃xff0c;在配置一套代理&＃xff0c;整个系统的逻辑变得更加复杂。

10&＃xff0c;Paxos

分布式一致性算法&＃xff0c;Paxos 算法处理的问题是一个分布式系统如何就某个值&＃xff08;决议&＃xff09;达成一致。这个算法被认为是同类算法中最有效的。Paxos与MySQL相结合可以实现在分布式的MySQL数据的强一致性。