从 MySQL 高可用架构看高可用架构设计

选自架构文摘公众号

高可用 HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务，我们说系统的可用性是 100%。如果系统每运行 100 个时间单位，会有 1 个时间单位无法提供服务，我们说系统的可用性是 99%。很多公司的高可用目标是 4 个 9，也就是 99.99%，这就意味着，系统的年停机时间为 8.76 个小时。

百度的搜索首页，是业内公认高可用保障非常出色的系统，甚至人们会通过 www.baidu.com 能不能访问来判断“网络的连通性”，百度高可用的服务让人留下啦“网络通畅，百度就能访问”，“百度打不开，应该是网络连不上”的印象，这其实是对百度 HA 最高的褒奖。

1. MySQL 高可用

说到 MySQL 的高可用，不得不提到复制，复制是 MySQL 高可用的基础。复制解决了什么问题呢？

实现数据备份
如果有从服务器，主服务器发生故障之后，开通从服务器的写入功能，从而提供高可用的使用功能
异地容灾
分摊负载（scale out ）主服务器：写、从服务器：读

1.1 主从复制流程

不同的复制协议：

1.2 高可用复制架构

1.3.mysql 高可用架构

1.3.1 MySQL Cluster 架构

限制存储引擎为 NDB 存储引擎：

1.3.2 MySQL+MMM 架构

MMM 即 Master-Master Replication Manager for MySQL（MySQL 主主复制管理器），是关于 MySQL 主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件（在任何时候只有一个节点可以被写入），这个套件也能基于标准的主从配置的任意数量的从服务器进行读负载均衡，所以你可以用它来在一组居于复制的服务器启动虚拟 ip，除此之外，它还有实现数据备份、节点之间重新同步功能的脚本。
MySQL 本身没有提供 replication failover 的解决方案，通过 MMM 方案能实现服务器的故障转移，从而实现 MySQL 的高可用。

此方案特点：

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

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

本文地址：从 MySQL 高可用架构看高可用架构设计
本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

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

4、同样可实现读写分离

1.3.3 MySQL+MHA 架构

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

此架构特点：

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

2、自动监控和故障转移

3、保障数据一致性

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

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

2.MySQL 高可用带给我们对高可用架构设计的思考

为了保证数据的一致性，MySQL 提出了复制的概念。

为了满足 acid，MySQL 提供了两种日志 redo 和 undo 日志，redo log 是重做日志，提供前滚操作，undo log 是回滚日志，提供回滚操作。undo log 不是 redo log 的逆向过程，其实它们都算是用来恢复的日志：redo log 通常是物理日志，记录的是数据页的物理修改，而不是某一行或某几行修改成怎样怎样，它用来恢复提交后的物理数据页(恢复数据页，且只能恢复到最后一次提交的位置)。undo 用来回滚行记录到某个版本。undo log 一般是逻辑日志，根据每行记录进行记录。为了高可用的保证，有了多主或者主从切换。

数据库的高可用架构一般在系统的底层，这方面的技术要求比较高，整个高可用系统大致如下：