MySQL集群高可用架构

拼搏现实的明天。 2022-01-29 06:25 374阅读 0赞

#### MySQL集群高可用架构 ####

前言

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更加复杂，对用户的服务可用，不仅仅是能访问，还要保证数据的正确性，因此数据库的高可用方案一直以来是讨论的热点

#### 1.MySQL主从架构 ####

此种架构，一般初创企业比较常用，以便于后面步步的扩展

![img][]

此架构的优点：

1.  成本低，部署快速、方便
2.  读写分离
3.  还能通过及时增加从库来减少读库压力

缺点：

1.  主库单点故障（主库异常故障，导致整个数据库无法及时拉起）
2.  数据库一致性问题（同步延迟造成）

#### 2.Heartbeat+DRBD+MySQL高可用架构 ####

**Heartbeat+DRBD+MySQL高可用架构方案与实施过程细节**

**互联网公司从初期到后期的数据库架构拓展**

![124150957.jpg][]

#### hearbeat ####

1.  #### hearbeat的作用 ####
    
    **通过heartbeat，可以将资源（IP及程序服务等资源）从一台已经故障的计算机快速转移到另一台正常运转的机器上继续提供服务，一般称之为高可用服务**。在实际生产中mkeepalived有很多相同之处。在生产实际的业务应用也是有区别的。
2.  工作原理
    
    通过修改heartbeat软件的配置文件，可以指定那一台heartbeat服务器作为主服务器，则另一台将自动称为热备服务器，然后在热备服务器上配置heartbeat守护进程来监听来服务器的心跳信息，如果热备服务器在指定实践内未监听到来自住服务器的心跳，就会启动故障转移程序，并获取服务器上的相关资源服务的所有权，接替服务继续不间断的提供服务，从而达到资源及服务高可用性的目的。这是heartbeat主备的模式。
    
    还可以支持主主模式，这时它们之间会相互发送报文给对方主机监听程序是否正常
    
    在heartbeat进行主备切换的时候，是需要时间的，首先是判断主宕机，然后从接替vip，启动从服务上面的程序（备机上面的程序本来是没有开启的）。
3.  heartbeat消息类型
    
    heartbeat高可用软件在工作过程中，一般来说，有三种消息类型，具体为：
    
     *  心跳信息
     *  集群转换信息
     *  重传请求
4.  心跳信息
    
    心跳消息为约150字节的数据包，可能为单播，广播或多播的方式，控制心跳频率及出现故障要等待多久进行故障转移。
5.  .集群转换消息
    
    当主服务器恢复在线状态时，通过ip-request消息要求备机释放主服务器失败时备服务器取得的资源及服务，备服务器释放资源和服务后，通过ip-request-resp消息通知主服务器它不在拥有该资源及服务，主服务器收到备节点的ip-request-resp消息通知后，启动失败时释放的资源及服务，并开始提供正常的访问服务。
6.  .重传请求
    
    rexmit-request控制重传心跳请求，次消息不太重要。
    
    提示：以上心跳控制消息都使用UDP协议发送到/etc/ha.d/ha.cf文件指定的任意端口，或指定的多播地址。

#### DRBD原理 ####

DRBD(Distributed Relicated Block Device 分布式复制块设备)， 可以解决磁盘单点故障。一般情况下只支持2个节点。

大致工作原理如下图：

![2][]

一般情况下文件写入磁盘的步骤是: 写操作 --> 文件系统 --> 内存缓存中 --> 磁盘调度器 --> 磁盘驱动器 --> 写入磁盘。而DRBD的工作机制如上图所示，数据经过buffer cache后有内核中的DRBD模块通过tcp/ip协议栈经过网卡和对方建立数据同步。

1.DRBD的工作模式

1.  主从模式 master/slave(primary/secondary)
    
    这种机制，在某一时刻只允许有一个主节点。主节点的作用是可以挂载使用，写入数据等；从节点作为主节点的镜像，是主节点的备份。
    
    这样的工作机制的好处是可以有效的避免磁盘出现单点故障，不会文件系统的错乱。
2.  双主模式 dula primary(primary / primary)
    
    所谓双主模型是2个节点都可以当做主节点来挂载使用。那么，思考这样一个问题？当第一个主节点对某一文件正在执行写操作，此时另一个节点也正在对同一文件也要执行写操作，结果会如何呢？？
    
    一般这种情况会造成文件系统的错乱，导致数据不能正常使用。原因是：对文件的加速机制是由操作系统内核所管理的，一个节点对文件加速之后，另一个节点并不知道对方的锁信息。
    
    解决办法是：使用集群文件系统。集群文件系统使用分布式文件锁管理器，当一个节点对文件加锁之后会通过某种机制来通知其他节点锁信息，从而实现文件锁共享。

#### heartbeat和keepalived应用场景及区别 ####

1、对于web，db，负载均衡(lvs,haproxy,nginx)等，heartbeat和keepalived都可以实现

2、lvs最好和keepalived结合，因为keepalived最初就是为lvs产生的，(heartbeat没有对RS的健康检查功能，heartbeat可以通过ldircetord来进行健康检查的功能)

3、mysql双主多从，NFS/MFS存储，他们的特点是需要数据同步，这样的业务最好使用heartbeat，因为heartbeat有自带的drbd脚本

总结：无数据同步的应用程序高可用可选择keepalived，有数据同步的应用程序高可用可选择heartbeat

#### 1、Heartbeat+DRBD+MySQL安装部署 ####

#### (1)、架构拓扑 ####

![124150265.jpg][]

架构说明：

1.实现了读写分离

2.读采用的DRBD的主从模式，多个从库可以使用lvs来提供读的负载均衡

3.写采用的DRBD的双主模式，保证了数据的同步，通过集群文件系统保证了数据写的安全，提高写效率

#### 3.MySQL+MHA架构 ####

MHA高可用架构是基于主从复制原理而部署的，是最常见，最主流的架构。

MHA原理：

MHA Manager可以单独部署在一台独立机器上管理多个master-slave集群,也可以部署在一台slave上.MHA Manager探测集群的node节点,当发现master出现故障的时候,它可以自动将具有最新数据的slave提升为新的master,然后将所有其它的slave导向新的master上.整个故障转移过程对应用程序是透明的。

目前MHA主要支持一主多从的架构，\*\*要搭建MHA,要求一个复制集群中必须最少有三台数据库服务器，\*\*一主二从，即一台充当master，一台充当备用master，另外一台充当从库

![img][img 1]

此架构特点：

1、安装布署简单，不影响现有架构

2、自动监控和故障转移

3、保障数据一致性

4、故障切换方式可使用手动或自动多向选择

5、适应范围大（适用任何存储引擎）

#### 4.MySQL+MMM架构 ####

![img][img 2]

解释下原理：

众所周知，MySQL自身提供了AB复制（主从复制），然后可以很轻松实现master-master双向复制，同时再为其中一个Master节点搭建一个Slave库。

这样就实现了MySQL-MMM架构的基础：master1和master2之间双向复制，同时Master1和Slave1之间是主从复制。这样整个体系中存在两个Master，正常情况下只有一个master对外提供写服务。如果对外提供服务的master意外宕机了，这是MySQL本身并不具备failover切换的能力，尽管集群中仍然有一个正常的master节点，但应用仍不可用。mysql-mmm就是为了解决这个问题诞生的。

MySQL-MMM是Master-Master Replication Manager for MySQL（mysql主主复制管理器）的简称，是Google的开源项目（Perl脚本），主要用来监控mysql主主复制并做失败转移。

其原理是将真实数据库节点的IP（RIP）映射为虚拟IP（VIP）集，在这个虚拟的VIP集中，有一个专用于write的VIP，多个用于read的VIP，这个用于Write的VIP映射着数据库集群中的两台master的真实IP（RIP），以此来实现Failover的切换，其他read的VIP可以用来均衡读（balance）。

此方案特点：

1、安全、稳定性较高，可扩展性好

2、 对服务器数量要求至少三台及以上

3、 对双主（主从复制性要求较高）

4、 同样可实现读写分离

[img]: /images/20220129/8fc090d32ae94673816a269bdd62c704.png
[124150957.jpg]: /images/20220129/a9aec17d62cb40d0a1cba2ebce9fbf9a.png
[2]: /images/20220129/b627f9391c3b437c85c4dc5a078d6962.png
[124150265.jpg]: /images/20220129/54840b67b0314802a0a9e741dad51f50.png
[img 1]: /images/20220129/2598f6bc2c40443f97820c0181a67eed.png
[img 2]: /images/20220129/1aa9aa6ca87747ada1f955ac6ddd5a29.png