MySQL集群技术概述

快来打我* 2022-08-08 11:44 205阅读 0赞

对于MySQL数据库来说，从比较早的版本开始，MySQL就支持master-slave复制，这个特性是MySQL数据库非常重要，而且也应用比较广泛的特性。MySQL复制在读写分离，数据备份，可伸缩性等方面都有比较好的应用，并结合其他特性，也很容易实现高可用性。

除了MySQL复制及MySQL官方的集群架构技术外，一些第三方公司也开发了很多工具用于实现MySQL集群的各种特性，整体来说，目前常见的MySQL集群架构类型有下面几种：

## **1.****mysql复制** ##

MySQL复制主要是通过在master节点上记录发生改变的binlog日志，slave节点从master节点获取日志，并在slave节点上应用，以实现slave节点与master节点的数据同步，与oracle数据库中的逻辑DataGuard实现方式比较相似。MySQL复制架构一般由以下几种应用方式：

**² ****一主多从：**

在主库读取请求压力非常大的场景下，可以通过配置一主多从复制架构实现读写分离，把大量对实时性要求不是特别高的读请求通过负载均衡分布到多个从库上，降低主库的读取压力。在主库出现异常宕机的情况下，可以把一个从库切换为主库继续提供服务；

**² ****级联复制：**

一主多从能够解决大部分读请求压力特别大的场景的需求，但主库的I/O压力和网络压力会随着从库的增加而增长，而使用多级复制架构就可以解决一主多从场景下，主库额外的I/O和网络压力。

但要注意的是，多级复制场景下主库的数据是经历两次才到达读取的从库，期间的延时比一主多从复制场景下只经历一次复制的要大。这种方案可以与第三方软件结合使用，例如Slave+LVS+Keepalived 实现高可用。

**² ****双主复制：Dual-Master 高可用环境**

双主/Dual Master架构适用于写压力比较大的场景，或者DBA做维护需要主从切换的场景，通过双主/Dual master架构避免了重复搭建从库的麻烦。

上面的三种MySQL复制方式可以相互结合，或者与其他第三方软件结合，形成新的mysql架构方案。

## **2. ****MySQL Cluster集群** ##

mysql cluster技术，这是mysql官方的集群，分为 SQL节点，管理节点，数据节点三个部分和层次，里面的mysql默认引擎均采用集群引擎NDB，而不是采用innodb存储引擎，之前做的不太成熟，有较多问题。最新版本为mysql cluster 7.4 ，有很多性能提升，但生产环境应该使用的还不太多。

## **3. ****MMM架构** ##

MMM架构，是用于管理双主环境的高可用方案，虽然多个主机，但同一时间只能够有一台主机执行写入操作，在发生故障时MMM会自动进行切换操作和IP漂移，保障高可用。但可能出现的问题是如果master2的数据落后于master1的数据，发生宕机时，业务切换到master2上，就无法保证数据的一致性，所以MMM不适合数据的一致性要求很高的场景。

## **4. ****MHA架构** ##

MHA技术 ，日本工程师开发的ha校本，能够比较好的实现MySQL HA需求，同时可以结合mysql 半同步集群实现数据同步，结合keeplive实现虚拟IP的切换，是正常生产环境中使用比较多的较成熟的mysql HA方案。在MySQL故障切换过程中，MHA能做到在0~30秒之间自动完成数据的故障切换操作，并且在进行故障切换过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

MHA由两部分组成：MHA Manager管理节点和MHA Node数据节点，MHA Manager可以单独部署在一台独立的机器上管理多个master-slave集群，也可以部署在一台slave上。MHA node运行在每台MySQL服务器上，MHA Manger会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的salve提升为新的master，然后将所有其他的salve重新指向新的master，整个故障转移过程中对应用程序是完全透明的。

目前很多互联网公司都是使用的MHA技术实现MySQL数据库的高可用保障。

## **5. ****Heartbeat+DRBD+mysql 架构 ** ##

Heartbeat+DRBD+mysql方案采用Heartbeat双机热备软件来保证数据库的高稳定性和连续性，数据的一致性由DRBD这个工具来保证。默认情况下只有一台mysql在工作，当主mysql服务器出现问题后，系统将自动切换到备机上继续提供服务，当主数据库修复完毕，又将服务切回继续由主mysql提供服务。

优点：安全性高、稳定性高、可用性高，出现故障自动切换，

缺点：只有一台服务器提供服务，成本相对较高。不方便扩展。可能会发生脑裂。

适用场景：

Heartbeat+DRBD+mysql方案适用于数据库访问量不太大，短期内访问量增长不会太快，对数据库可用性要求非常高的场景。

## **6. ****Lvs+Keepalived+Mysql单写读负载均衡高可用方案** ##

Lvs+keepalived\+mysql高可用解决方案，lvs提供负载均衡，keepalived作为故障转移，提高系统的可用性。但是一般的mysql高可用为了实现mysql数据的一致性，一般都是采用单点写入，本方案采用keepalived中的sorry\_server来实现写入数据库为单点的需求，读负载均衡通过lvs实现，读能自由的实现负载均衡和故障切换。本方案实现的功能是当网络有问题、mysql有问题、服务器宕机、keepalived服务停止后,服务器能自动跳转到备用机，当主服务器服务启动起来后会自动切换回来。

**² ****优点：**

实现方便，高可用效率好，可以根据服务与系统的可用性多方面进行切换。

可以将写VIP和读VIP分别进行设置，为读写分离做准备。

扩展很方便。可以在后面添加多个从服务器，并做到负载均衡。

**² ****缺点：**

在启动或者恢复后会立即替换掉定义的sorry\_server，因此如果要实现指定条件替换或者不替换需要通过其他方式实现，比如：临时更改mysql的端口等。

安装配置比单写入稍微复杂，需要另外一个VIP。管理比单写入复杂。

主切换后从需要手工切换。

切换需要1s左右的时间。

**² ****适用场景****：**

这个方案适用于只有两台数据库服务器（后端有多个从服务器也是可以的，只是要手工切换从服务器比较麻烦，后面会介绍的MMM能将从服务器自动切换）并且还能实现数据库的读写分离的情况，这样backup机器也能用起来，提高系统资源的利用率，减少master端的负载。应用中读数据库配置读VIP，写数据库配置写VIP。这个方案也能够很方便的进行单台数据库的管理维护以及切换工作。比如进行大表的表结构更改、数据库的升级等都是非常方便的。

## **7. ****Percona XtraDB Cluster高可用性和可扩展性****架构** ##

Percona XtraDBCluster提供的特性有：

1.同步复制，事务要么在所有节点提交或不提交。

2.多主复制，可以在任意节点进行写操作。

3.在从服务器上并行应用事件，真正意义上的并行复制。

4.节点自动配置。

5.数据一致性，不再是异步复制。

Percona XtraDBCluster完全兼容MySQL和Percona Server，表现在：

1.数据的兼容性

2.应用程序的兼容性：无需更改应用程序

**² ****集群特点： **

集群是有节点组成的，推荐配置至少3个节点，但是也可以运行在2个节点上。