Mysql集群方案简介

Mysql集群方案简介集群的好处高可用性：故障检测及迁移，多节点备份。可伸缩性：新增数据库节点便利，方便扩容。负载均衡：切换某服务访问某节点，分摊单个节点的数据库压力。集群要考虑的风险网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法...

Y先森0.0

3169人浏览 · 2022-05-06 20:14:00

Y先森0.0 · 2022-05-06 20:14:00 发布

Mysql集群方案简介

集群的好处

高可用性：故障检测及迁移，多节点备份。
可伸缩性：新增数据库节点便利，方便扩容。
负载均衡：切换某服务访问某节点，分摊单个节点的数据库压力。

集群要考虑的风险

网络分裂：群集还可能由于网络故障而拆分为多个部分，每部分内的节点相互连接，但各部分之间的节点失去连接。
脑裂：导致数据库节点彼此独立运行的集群故障称为“脑裂”。这种情况可能导致数据不一致，并且无法修复，例如当两个数据库节点独立更新同一表上的同一行时。

大致有6种方案

mysql官方提供的方案
- MySQL Replication
- MySQL Fabirc
- MySQL Cluster
第三方方案
- MMM (Master Replication Manager for MySQL)
依托硬件的方案
- 心跳检测+SAN共享存储
- 心跳检测+DRDB磁盘复制

mysql官方提供的方案

方案1：MySQL Replication

mysql复制(MySQL Replication)，是mysql自带的功能。

主从复制是通过重放binlog实现主库数据的异步复制。即当主库执行了一条sql命令，那么在从库同样的执行一遍，从而达到主从复制的效果。

MySQL Replication是一主多从的结构，主要目的是实现数据的多点备份(没有故障自动转移和负载均衡)。

相比于单个的mysql，一主多从下的优势如下：

1.读写分离，负载均衡

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

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

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

其劣势为：

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

方案2：MySQL Fabirc

mysql官方提供的，这是在MySQL Replication的基础上，增加了故障检测与转移，自动数据分片功能。

不过依旧是一主多从的结构

MySQL Fabirc只有一个主节点，区别是当该主节点挂了以后，会从从节点中选择一个来当主节点。

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

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

其劣势为：

从库要从binlog获取数据并重放，这肯定与主库写入数据存在时间延迟，因此从库的数据总是要滞后主库。
对主库与从库之间的网络延迟要求较高，若网络延迟太高，将加重上述的滞后，造成最终数据的不一致。
事务及查询只支持在同一个分片内，事务中更新的数据不能跨分片，查询语句返回的数据也不能跨分片。
节点故障恢复30秒或更长(采用InnoDB存储引擎的都这样)。

分片：分片可以简单定义为将大数据库分布到多个物理节点上的一个分区方案。每一个分区包含数据库的某一部分，称为一个片

分区：分区则是把一张表的数据分成 N 多个区块，这些区块可以在同一个磁盘上，也可以在不同的磁盘上。

方案3：MySQL Cluster

mysql官方提供的，多主多从结构

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

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

其劣势为：

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

第三方方案

方案4：MMM (Master Replication Manager for MySQL)

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

MMM(Master Replication Manager for MySQL)是双主多从结构

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

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

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

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

其劣势为：

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