MySQL常见的高可用架构

Posted 2023-04-04 杨羊羊咩咩～

mysql常见的高可用架构

• • 概述：
  • 1.基于共享存储的方案SAN
  • • • 优点:
      • 限制或缺点:
  • 2.基于磁盘复制的方案 MySQL+DRDB架构
  • • • 优点：
      • 限制或缺点：
  • 3、MySQL+MHA架构
  • • • 优点：
      • 缺点：
  • 4、MySQL+MMM架构
  • • • 优点：
      • 缺点：
      • 服务器资源：

概述：

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称7天24小时不间断服务，但多多少少有一些时候服务不可用，比如某些时候网页打不开，百度不能搜索或者无法发微博，发微信等。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，一般会同时考虑方案中数据一致性问题。

1.基于共享存储的方案SAN

方案介绍：SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动MySQL。

优点:

1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应用透明。
3.保证主备数据的强一致。

限制或缺点:

1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格比价昂贵。

2.基于磁盘复制的方案 MySQL+DRDB架构

通过DRBD基于block块的复制模式，快速进行双主故障切换，很大程度上解决主库单点故障问题。
方案介绍：DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD与SAN类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过DRBD的数据是复制存储，不是共享存储。DRBD的架构图如下：

优点：

1.切换对应用透明。
2.保证主备数据的强一致。

限制或缺点：

1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2.一般配置两节点同步，可扩展性比较差。
3.备库不能提供读服务，资源浪费。

3、MySQL+MHA架构

MHA目前在Mysql高可用方案中应该也是比较成熟和常见的方案，它由日本人开发出来，在mysql故障切换过程中，MHA能做到快速自动切换操作，而且还能最大限度保持数据的一致性。

优点：

1、 代码开源，方便结合业务场景二次开发
2、故障切换时，可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。
3、 可以灵活选择VIP方案或者全局目录数据库方案(更改Master IP映射)来进行切换。

缺点：

1、无法保证强一致，因为从故障Master上保存二进制日志并不总是可行，比如Master磁盘坏了，或者SSH认证失败等。
2、只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。
3、采用全局目录数据库方案切换时，需要应用感知变化，因此对应用不透明，因此要保持切换对应用透明，依然依赖于VIP。
4、不适用于大规模集群部署，配置比较复杂。
5、MHA管理节点本身的HA无法保证。

4、MySQL+MMM架构

MMM即Master-Master Replication Manager for MySQL（mysql主主复制管理器），是关于mysql主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。

优点：

1、安全、稳定性较高，可扩展性好
2、对服务器数量要求至少三台及以上
3、双主热备模式，读写分离，SLAVE集群可线性扩展（主从复制性要求较高）
4、 同样可实现读写分离。

缺点：

读写分离需要在程序端解决，Master大批量写操作时会产生主从延时

服务器资源：

1、至少五台PC Server，2台MySQL主库，2台MySQL从库，1台MMM Monitor；
2、1台MMM Monitor选择低配；
3、如果不采用F5作为从库的负载均衡器，可用2台PC SERVER部署LVS或HAProxy+Keepalived组合来代替；

参考资料：
https://www.likecs.com/show-855612.html
https://www.jb51.net/article/83400.htm
官方文档：
https://dev.mysql.com/doc/refman/8.0/en/mysql-innodb-cluster-introduction.html

MySQL技术专题「架构分析系列」分析MySQL的高可用架构技术分析和指南

背景说明

随着信息技术的发展，企业越来越依赖于信息化管理，各业务应用的数据信息，主要存储在数据库中，企业对这些数据访问的连续性要求越来越高，为了避免因为数据的中断导致各种损失，数据库的高可用已成了企业信息化建设的重中之中。同时，对于电信、金融、能源、军工等等涉及国计民生的行业或领域的关键业务对于关键数据存储都需要高可用，必须保证数据系统7×24小时全天候运行，防止数据丢失、数据损坏。

高可用架构介绍

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

MySQL高可用架构分类

• MySQL实现高可用之MMM
• MySQL实现高可用之MHA
• MySQL实现高可用之主从架构
• MySQL实现高可用之Cluster模式

MMM的技术分析

MMM（Master-Master replication manager for MySQL）是一套支持双主故障切换和双主日常管理的脚本程序。

• MMM使用Perl语言开发，主要用来监控和管理MySQL Master-Master（双主）复制，虽然叫做双主复制，但是业务上同一时刻只允许对一个主进行写入，另一台备选主上提供部分读服务，以加速在主主切换时刻备选主的预热

• MMM的监控端是会提供多个虚拟ip（vip），包括一个可写的vip，多个可读的vip，通过监管的管理，这些ip会绑定在可用的mysql上，当某一台mysql宕机时，会将vip迁移到其他mysql。

• MMM这套脚本程序一方面实现了故障切换的功能，另一方面其内部附加的工具脚本也可以实现多个slave的read负载均衡。

• 这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。

MMM的基础组件分析

• mmm_mond：监控进程，负责所有的监控工作，决定和处理所有节点角色活动。因此，脚本需要在监管上运行。
• mmm_agentd：运行在每个msql服务器上的代理进程，完成监控的探针工作和执行简单的远端服务设置。此脚本需要在被监管机上运行。
• mmm_control：一个简单的脚本，提供管理mmm_mond进行的命令。

MMM实现基本实现原理

MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。

MySQL本身没有提供replication failover的解决方案，通过MMM方案能实现服务器的故障转移，从而实现mysql的高可用。

MMM的使用场景

由于MMM无法完全的保证数据一致性，所以MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。

对于那些对数据的一致性要求很高的业务，非常不建议采用MMM这种高可用架构。

• MMM项目来自 Google：http://code.google.com/p/mysql-master-master
• 官方网站为：http://mysql-mmm.org

MHA简介

MHA（Master High Availability）目前在MySQL高可用方面是一个相对成熟的解决方案，它由日本DeNA公司的youshimaton（现就职于Facebook公司）开发，是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

• MHA是一款开源的MySQL高可用程序，MHA在监控到master节点故障时，会自动提升其中拥有最新数据的slave节点成为新的master节点。

• MHA会获取其他节点的额外信息来避免一致性方面的问题，也就是MHA会获取其他从节点中的数据信息，并将信息发给最接近主节点的从节点，这样主节点故障时会提升此从节点为主节点，而此从节点拥有其他从节点所有的数据信息。

• MHA还提供了master节点的在线切换功能，即按需切换master/slave节点。

MHA的基础组件

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。

MHA Manager可以单独部署在独立的机器上管理多个master-slave集群，也可以部署在一台slave节点上。

MHA的实现原理

• MHA Node运行在每台MySQL服务器上，MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master。整个故障转移过程对应用程序完全透明。
• 在MHA自动故障切换过程中，MHA试图从宕机的主服务器上保存二进制日志，最大程度的保证数据的不丢失，但这并不总是可行的。
• 例如，如果主服务器硬件故障或无法通过ssh访问，MHA没法保存二进制日志，只进行故障转移而丢失了最新的数据。使用MySQL 5.5的半同步复制，可以降低数据丢失的风险。
• MHA可以与半同步复制结合起来，如果只有一个slave已经收到了最新的二进制日志，MHA可以将最新的二进制日志应用于其他所有的slave服务器上，因此可以保证所有节点的数据一致性。

MHA的使用场景

目前MHA主要支持一主多从的架构。

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

• 因为至少需要三台服务器，出于机器成本的考虑，淘宝也在该基础上进行了改造，目前淘宝TMHA已经支持一主一从。

• 从代码层面看，MHA就是一套Perl脚本，那么相信以阿里系的技术实力，将MHA改成支持一主一从也并非难事。

MySQL主从架构

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

此架构特点

1. 成本低，布署快速、方便
2. 读写分离
3. 还能通过及时增加从库来减少读库压力
4. 主库单点故障
5. 数据一致性问题（同步延迟造成）

1. 高可用软件可使用Heartbeat,全面负责VIP、数据与DRBD服务的管理
2. 主故障后可自动快速切换，并且从库仍然能通过VIP与新主库进行数据同步
3. 从库也支持读写分离，可使用中间件或程序实现

MySQL Cluster概述

MySQL Cluster技术在分布式系统中为MySQL提供了冗余特性，增强了安全性，可以的提高系统的可靠性和数据的有效性。MySQL集群需要一组计算机，每台计算机可以理解为一个节点，这些节点的功能各不相同。MySQL Cluster按照功能来分，可以分为三种节点：管理节点、数据节点和SQL节点。集群中的某台计算机可以是某一个节点，也可以是两种或者三种节点的集合，这些节点组合在一起，为应用提供具有高可靠性、高性能的Cluster数据管理；

目前企业数据量越来越大，所以对MySQL的要求进一步提高，以前的大部分高可用方案通常存在一定的缺陷，例如MySQL Replication方案，Master是否存活检测需要一定的时间，如果需要主从切换也需要一定的时间，因此高可用很大的程度上依赖于监控软件和自动化管理工具。随着MySQL Cluster的不断发展，终于在性能和高可用上得到了很大的提高；

MySQL Cluster基本概念

MySQL Cluster简单地讲是一种MySQL集群的技术，是由一组计算机构成，每台计算机可以存放一个或者多个节点，其中包括MySQL服务器，DNB Cluster的数据节点，管理其他节点，以及专门的数据访问程序，这些节点组合在一起，就可以为应用提高可高性能、高可用性和可缩放性的Cluster数据管理；

MySQL Cluster的访问过程大致是这样的，应用通常使用一定的负载均衡算法将对数据访问分散到不同的SQL节点，SQL节点对数据节点进行数据访问并从数据节点返回数据结果，管理节点仅仅只是对SQL节点和数据节点进行配置管理；

理解MySQL Cluster节点

MySQL Cluster按照节点类型可以分为3种类型的节点，分别是管理节点、SQL节点、数据节点，所有的这些节点构成了一个完整的MySQL集群体系，事实上，数据保存在NDB存储服务器的存储引擎中，表结构则保存在MySQL服务器中，应用程序通过MySQL服务器访问数据，而集群管理服务器则通过管理工具ndb_mgmd来管理NDB存储服务器；

【1.管理节点】

管理节点主要是用来对其他的节点进行管理。通常通过配置config.ini文件来配置集群中有多少需要维护的副本、配置每个数据节点上为数据和索引分配多少内存、IP地址、以及在每个数据节点上保存数据的磁盘路径；

管理节点通常管理Cluster配置文件和Cluster日志。Cluster中的每个节点从管理服务器检索配置信息，并请求确定管理服务器所在位置的方式。如果节点内出现新的事件的时候，节点将这类事件的信息传输到管理服务器，将这类信息写入到Cluster日志中；

一般在MySQL Cluster体系中至少需要一个管理节点，另外值得注意的是，因为数据节点和SQL节点在启动之前需要读取Cluster的配置信息，所以通常管理节点是最先启动的；

【2.SQL节点】

SQL节点简单地讲就是mysqld服务器，应用不能直接访问数据节点，只能通过SQL节点访问数据节点来返回数据。任何一个SQL节点都是连接到所有的存储节点的，所以当人任何一个存储节点发生故障的时候，SQL节点都可以把请求转移到另一个存储节点执行。通常来讲，SQL节点越多越好，SQL节点越多，分配到每个SQL节点的负载就越小，系统的整体性能就越好；

【3.数据节点】

数据节点用来存放Cluster里面的数据，MySQL Cluster在各个数据节点之间复制数据，任何一个节点发生了故障，始终会有另外的数据节点存储数据；

通常这3种不同逻辑的节点可以分布在不同的计算机上面，集群最少有3台计算机，为了保证能够正常维护集群服务，通常将管理节点放在一个单独的主机上；