mysql集群搭建方案对比

古城微笑少年丶 2022-12-17 01:19 212阅读 0赞

# 一、数据库系统体系结构 #

数据库系统的体系结构受数据库系统运行所在的底层计算机系统的影响很大。数据库系统可以是集中式的，其中由一台服务器机器执行数据库上的操作。数据库系统也可以设计为并行计算机体系结构。分布式数据库则跨越多个地理位置上分离的机器。

分布式数据库又分成同构分布式数据库和异构分布式数据库。同构分布式系统中，所有站点都使用相同的数据库管理软件，彼此了解，共同合作处理用户的请求。在同构分布式系统中，放弃了系统部分自治性，以及修改模式或者数据库管理系统软件。为了使事务五处理能在多个站点间进行，必须和其他站点合作来交换与事务相关的信息。而异构分布式数据库中，站点之间彼此不了解。

分布式数据库透明性，数据冗余性，易于扩展性，自治性。

# 二、mysql集群 #

mysql 集群是 mysql 适合于分布式计算环境的高可用、高冗余版本。它采用了 NDB Cluster 存储引擎，允许在 1 个群集中运行多个 MySQL 服务器。在 MySQL 5.0 及以上的二进制版本中，以及与最新的 Linux 版本兼容的 RPM 包中提供了该存储引擎。

mysql 群集是一种技术，该技术允许在无共享的系统中部署“内存中”和“磁盘中”数据库的 Cluster 。通过无共享体系结构，系统能够使用廉价的硬件，而且对软硬件无特殊要求。此外，由于每个组件有自己的内存和磁盘，不存在单点故障。MySQL Cluster 由一组计算机构成，每台计算机上均运行着多种进程，包括 MySQL 服务器，NDB Cluster 的数据节点，管理服务器，以及（可能存在的）专门的数据访问程序。

管理服务器(MGM节点)负责管理 Cluster 配置文件和 Cluster 日志。Cluster 中的每个节点从管理服务器检索配置数据。

当数据节点内出现新的事件时，节点将关于这类事件的信息传输到管理服务器，然后，将这类信息写入 Cluster 日志。

目前能够运行 MySQL Cluster 的操作系统有 Linux、Mac OS X 和 Solaris，最新的版本已经支持 Windows 操作系统。

MySQL 群集的数据节点之间的通信是不加密的，并且需要高速的带宽，所以建议把群集建立在一个高速局域网内，不建议跨网段、跨公网的部署这种系统体系。

MySQL 群集分为三种节点：管理节点，数据节点和SQL节点。

管理节点：主要用于管理各个节点，能够通过命令对某个节点进行重启、关闭、启动等操作。也能够监视全部节点的工作状态。

数据节点：主要是对数据的存储，不提供其他的服务。

SQL节点：主要是对外提供SQL功能，类似一台普通的 MySQL Server。

而SQL节点和数据节点可以是同一台机器，也就是说这台机器即是SQL节点也是数据节点。它们只是逻辑关系上的划分，实际部署时，甚至所有的阶段都可以位于同一台物理机器上，只是配置较复杂些。

# 三、MySQL Cluster的优缺点 #

优点：

1.  99.999 ％的高可用性
2.  快速的自动失效切换
3.  灵活的分布式体系结构，没有单点故障
4.  高吞吐量和低延迟
5.  可扩展性强，支持在线扩容

缺点：

1.  存在很多限制，比如：不支持外键，数据行不能超过8K（不包括BLOB和text中的数据）
2.  部署、管理、配置很复杂
3.  占用磁盘空间大，内存大
4.  备份和恢复不方便
5.  重启的时候，数据节点将数据load到内存需要很长时间

# 四、mysql集群方案优劣 #

### 一，mysql原厂出品 ###

1，MySQL Replication

mysql复制（MySQL Replication），是mysql自带的功能。

原理简介：

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

![5f451a1edc22c28af6e32a29b37403dc.png][] MySQL Replication一主多从的结构，主要目的是实现数据的多点备份（没有故障自动转移和负载均衡）。相比于单个的mysql，一主多从下的优势如下：

*  如果让后台读操作连接从数据库，让写操作连接主数据库，能起到读写分离的作用，这个时候多个从数据库可以做负载均衡。
 *  可以在某个从数据库中暂时中断复制进程，来备份数据，从而不影响主数据的对外服务（如果在master上执行backup，需要让master处于readonly状态，这也意味这所有的write请求需要阻塞）。

就各个集群方案来说，其优势为：

*  主从复制是mysql自带的，无需借助第三方。
 *  数据被删除，可以从binlog日志中恢复。
 *  配置较为简单方便。

其劣势为：

*  从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
 *  对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
 *  单一的主节点挂了，将不能对外提供写服务。

2，MySQL Fabirc

mysql织物（MySQL Fabirc），是mysql官方提供的。

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

就各个集群方案来说，其优势为：

*  mysql官方提供的工具，无需第三方插件。
 *  数据被删除，可以从binlog日志中恢复。
 *  主节点挂了以后，能够自动从从节点中选择一个来当主节点，不影响持续对外提供写服务。

其劣势为：

*  从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
 *  对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
 *  2014年5月推出的产品，数据库资历较浅，应用案例不多，网上各种资料相对较少。
 *  事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
 *  节点故障恢复30秒或更长（采用InnoDB存储引擎的都这样）。

3，MySQL Cluster

mysql集群（MySQL Cluster）也是mysql官方提供的。

MySQL Cluster是多主多从结构的

就各个集群方案来说，其优势为：

*  mysql官方提供的工具，无需第三方插件。
 *  高可用性优秀，99.999%的可用性，可以自动切分数据，能跨节点冗余数据（其数据集并不是存储某个特定的MySQL实例上，而是被分布在多个Data Nodes中，即一个table的数据可能被分散在多个物理节点上，任何数据都会在多个Data Nodes上冗余备份。任何一个数据变更操作，都将在一组Data Nodes上同步，以保证数据的一致性）。
 *  可伸缩性优秀，能自动切分数据，方便数据库的水平拓展。
 *  负载均衡优秀，可同时用于读操作、写操作都都密集的应用，也可以使用SQL和NOSQL接口访问数据。
 *  多个主节点，没有单点故障的问题，节点故障恢复通常小于1秒。

其劣势为：

*  架构模式和原理很复杂。
 *  只能使用存储引擎 NDB ，与平常使用的InnoDB 有很多明显的差距。比如在事务（其事务隔离级别只支持Read Committed，即一个事务在提交前，查询不到在事务内所做的修改），外键（虽然最新的NDB 存储引擎已经支持外键，但性能有问题，因为外键所关联的记录可能在别的分片节点），表限制上的不同，可能会导致日常开发出现意外。[点击查看具体差距比较][Link 1]
 *  作为分布式的数据库系统，各个节点之间存在大量的数据通讯，比如所有访问都是需要经过超过一个节点（至少有一个 SQL Node和一个 NDB Node）才能完成，因此对节点之间的内部互联网络带宽要求高。
 *  Data Node数据会被尽量放在内存中，对内存要求大，而且重启的时候，数据节点将数据load到内存需要很长时间。

官方的三兄弟的区别对比如下图所示；

![e30e29217b6df7d9ae027fefe4348a1e.png][]

4，MySQL Group Replication

MGR(MySQL Group Replication)是 MySQL 自带的一个插件，可以灵活部署。

MySQL MGR 集群是多个 MySQL Server 节点共同组成的分布式集群，每个 Server 都有完整的副本，它是基于 ROW 格式的二进制日志文件和 GTID 特性。

支持多主模式，但官方推荐单主模式：

多主模式下，客户端可以随机向MySQL节点写入数据

单主模式下，MGR集群会选出primary节点负责写请求，primary节点与其它节点都可以进行读请求处理.

![96a6cf33f225563a2b898948fc2008af.png][]

优点：

*  基本无延迟，延迟比异步的小很多
 *  支持多写模式，但是目前还不是很成熟(由于事务冲突检测采用的是fist\_commit\_wins的方式，多主并发冲突高的场景下可能会出现很多事务失败回滚的情况，需要规避；)
 *  数据的强一致性，可以保证数据事务不丢失
 *  金融级分布式数据库,高可用、高扩展、高可靠,MGR天生就是为金融场景设计的，例如：支付，证券交易，保险，银行等等。因为这些场景要求数据必须做到零丢失，数据库可用性在4个9，甚至5个9（年度停机时间不超过5分钟）。
 *  MGR采用多副本，在2N+1个节点集群中，集群只要N +1个节点还存活着，数据库就能稳定的对外提供服务。

缺点:

*  仅支持innodb
 *  只能用在GTID模式下，且日志格式为row格式

### 二，mysql第三方优化 ###

5，MMM

MMM是在MySQL Replication的基础上，对其进行优化。

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

![35f8197514e2f533b58722baed8c56c1.png][]

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

就各个集群方案来说，其优势为：

*  自动的主主Failover切换，一般3s以内切换备机。
 *  多个从节点读的负载均衡。

其劣势为：

*  无法完全保证数据的一致性。如主1挂了，MMM monitor已经切换到主2上来了，而若此时双主复制中，主2数据落后于主1（即还未完全复制完毕），那么此时的主2已经成为主节点，对外提供写服务，从而导致数据不一。
 *  由于是使用虚拟IP浮动技术，类似Keepalived，故RIP（真实IP）要和VIP（虚拟IP）在同一网段。如果是在不同网段也可以，需要用到虚拟路由技术。但是绝对要在同一个IDC机房，不可跨IDC机房组建集群。

6，MHA

MHA是在MySQL Replication的基础上，对其进行优化。

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

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

![fc544e6e5c602a3483b94220f9bdfabb.png][] 就各个集群方案来说，其优势为：

*  可以进行故障的自动检测和转移
 *  具备自动数据补偿能力，在主库异常崩溃时能够最大程度的保证数据的一致性。

其劣势为：

*  MHA架构实现读写分离，最佳实践是在应用开发设计时提前规划读写分离事宜，在使用时设置两个连接池，即读连接池与写连接池，也可以选择折中方案即引入SQL Proxy。但无论如何都需要改动代码；
 *  关于读负载均衡可以使用F5、LVS、HAPROXY或者SQL Proxy等工具，只要能实现负载均衡、故障检查及备升级为主后的读写剥离功能即可，建议使用LVS

7，Galera Cluster

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

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

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

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

![896f18b0bc2a23f9ef8eefa12b74dc92.png][] 就各个集群方案来说，其优势为：

*  多主多活下，可对任一节点进行读写操作，就算某个节点挂了，也不影响其它的节点的读写，都不需要做故障切换操作，也不会中断整个集群对外提供的服务。
 *  拓展性优秀，新增节点会自动拉取在线节点的数据（当有新节点加入时，集群会选择出一个Donor Node为新节点提供数据），最终集群所有节点数据一致，而不需要手动备份恢复。

其劣势为：

*  能做到数据的强一致性，毫无疑问，也是以牺牲性能为代价。

### 三，依托硬件配合 ###

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

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

8，heartbeat+SAN

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

![ac488be8cf70111b763a0fb7856f20d2.png][]

就各个集群方案来说，其优势为：

*  保证数据的强一致性；
 *  与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；

其劣势为：

*  SAN价格昂贵；

9，heartbeat+DRDB

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

![cb9b7bc1ff05d8e588dcf6aac3950383.png][]

就各个集群方案来说，其优势为：

*  相比于SAN储存网络，价格低廉；
 *  保证数据的强一致性；
 *  与mysql解耦，不会由于mysql的逻辑错误发生数据不一致的情况；

其劣势为：

*  对io性能影响较大；
 *  从库不提供读操作；

### 四，其它 ###

10，Zookeeper + proxy

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

![464f6c21e4160caa5ba3a7786d1c447f.png][]

就各个集群方案来说，其优势为：

*  扩展性较好，可以扩展为大规模集群。

缺其劣势为：

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

11，Paxos

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

![e115de70073522184937af755e8c1382.png][]

[5f451a1edc22c28af6e32a29b37403dc.png]: /images/20221123/8f86926f00fc4ae99ac466ba9d658da9.png
[Link 1]: https://dev.mysql.com/doc/mysql-cluster-excerpt/8.0/en/mysql-cluster-ndb-innodb-engines.html
[e30e29217b6df7d9ae027fefe4348a1e.png]: /images/20221123/6515ade8c22a455fba42c0cf0d6a8077.png
[96a6cf33f225563a2b898948fc2008af.png]: /images/20221123/6839ccf639f24bfcb3d29482c795bb1b.png
[35f8197514e2f533b58722baed8c56c1.png]: /images/20221123/6dc70e72891f4c278db8b42a15d68ede.png
[fc544e6e5c602a3483b94220f9bdfabb.png]: /images/20221123/082ffee7a27f4468b547619524d9d0f4.png
[896f18b0bc2a23f9ef8eefa12b74dc92.png]: /images/20221123/1aa4224417a444ed876c61eee63bf0cc.png
[ac488be8cf70111b763a0fb7856f20d2.png]: /images/20221123/5d713d8ef6bf404fbba58fad71a1ab57.png
[cb9b7bc1ff05d8e588dcf6aac3950383.png]: /images/20221123/688bdaa1e83d4e1d82f8d8cb8908ef05.png
[464f6c21e4160caa5ba3a7786d1c447f.png]: /images/20221123/71c03ddb9bb842758955609ac3538d7b.png
[e115de70073522184937af755e8c1382.png]: /images/20221123/ba468bb6578f411ba1ed5f00d3c53bd6.png