共计 4468 个字符，预计需要花费 12 分钟才能阅读完成。
这篇文章主要介绍“MySQL 的高可用架构技术是什么”，在日常操作中，相信很多人在 MySQL 的高可用架构技术是什么问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”MySQL 的高可用架构技术是什么”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！
背景说明
随着信息技术的发展，企业越来越依赖于信息化管理，各业务应用的数据信息，主要存储在数据库中，企业对这些数据访问的连续性要求越来越高，为了避免因为数据的中断导致各种损失，数据库的高可用已成了企业信息化建设的重中之中。同时，对于电信、金融、能源、军工等等涉及国计民生的行业或领域的关键业务对于关键数据存储都需要高可用，必须保证数据系统 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：code.google.com/p/mysql-mas…
官方网站为：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 主从架构
此种架构，一般初创企业比较常用，也便于后面步步的扩展
此架构特点
成本低，布署快速、方便
读写分离
还能通过及时增加从库来减少读库压力
主库单点故障
数据一致性问题（同步延迟造成）
高可用软件可使用 Heartbeat, 全面负责 VIP、数据与 DRBD 服务的管理
主故障后可自动快速切换，并且从库仍然能通过 VIP 与新主库进行数据同步
从库也支持读写分离，可使用中间件或程序实现
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 台计算机，为了保证能够正常维护集群服务，通常将管理节点放在一个单独的主机上。
到此，关于“MySQL 的高可用架构技术是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！
