A+文档丨Azure MySQL 数据库高可用性解析

去年年底，Azure Database for MySQL Flexible Server 登陆中国大陆。用户可通过二十一世纪互联运营的Microsoft Azure体验。

本期A+文档与你共同解析Azure Database for MySQL Flexible Server 高可用性背后的底层逻辑。

数据库是整个 IT 系统中必不可少服务之一，其高可用性也一直是系统设计环节中的关键考虑要素。在评估 MySQL 数据库的高可用性时，主要考虑两个方面：

如果数据库发生了故障，如宕机、网络中断以及其他意外情况导致数据库服务不可用，如何能尽快恢复数据库服务的可用性，将停机时间尽可能地减少，从而保证业务的连续性，即 RTO（故障时间容错）。

当副本数据库作为备用节点进行高可用故障转移后，其数据内容应当与原主节点数据库保持一致；如何保证在发生如上所述的数据库故障转移切换后，不会发生数据丢失或数据不一致，即 RPO（数据丢失容错）。

Azure Database for MySQL Flexible Server 在这两方面的实现状况如何？

为了充分理解 Azure MySQL 的高可用设计原理，我们先从 Azure MySQL 数据库服务本身的架构设计聊起。

以上图中的单台服务器部署为例，Azure MySQL 采用了存算分离的架构。在存储层，使用了 Azure Premium Storage，它用于存储数据库文件、事务日志和、MySQL 服务器日志等，它会在本地同步复制三个冗余副本来确保数据持久性。此三副本间采用本地冗余存储（LRS）进行复制，对其的写入请求是同步发生的，这意味着必须将数据写入到所有的三个副本后，该写入操作才会返回成功。

除此之外，Azure MySQL 还将自动创建服务器备份（Backups），并将它们存储在本地冗余、区域冗余或异地冗余备份存储中，这些备份文件可以用于还原 Azure MySQL 服务器。

在探讨 Azure MySQL 的高可用性逻辑之前，我们先来回顾一下原生 MySQL 的主从复制是怎么做的。

在上图中可以看到，首先主库 MySQL 服务器会将数据修改记入 Binlog 日志中。当有从库连接到主库服务器并指定 Binlog 日志文件的读取起点位置后，主库和从库会分别创建一个 Dump 线程和一个 I/O 线程并建立连接。通过该连接，从库向主库发送了 Binlog 读取请求，主库根据该请求的内容向从库发送 Binlog 日志。从库的 I/O 线程在接受到 Binlog 日志后，会将其写入自己的 Relay log 中，并创建一个 SQL 线程将 Relay log 中的具体内容进行 Replay，从而使从库的 数据与主库保持一致。

这种 MySQL 原生的主从复制机制在默认情况下是异步进行的。主数据库在执行客户端提交的事务后，将其写入到自己的 Binlog 日志文件中，随后立即将返回一个成功相应给到客户端。由于与从库 Binlog 同步这个过程是异步的，主库无法得知 Binlog 文件是否已成功同步到了从库中，因此，如果在从库接收到主库发送过来的 Binlog 日志之前，主库发生了故障导致服务中断，就可能会导致主从库之间数据不一致的情况。

避免这种情况的常见方案是采用半同步复制，这也是最简单的 MySQL 集群高可用方案之一。依赖于半同步复制，主库等待从库接收 Binlog 日志并写到 Relay log 中之后才会返回给客户端该事务成功的反馈，从而在一定程度上保证了主库和从库之间的数据一致性。

但同时，半同步复制也会带来一系列问题。其中一个是会造成主库较大的写入延迟，对数据库服务的性能产生影响；另一方面，如果从服务器发生故障，主库就必须等待从服务器恢复正常才能完成写入；或者设置超时降级策略退回异步复制，也无法保证数据一致性。因此，对于高可用性架构目前更多采用一些优化的方案，如双通道复制、共享存储等。

Azure MySQL 支持服务器高可用性，它将帮助 MySQL 数据库实现自动故障转移并保证已提交 的数据永远不会因为服务器发生故障而丢失。

此处以区域冗余高可用性为例，即在同一 Azure 区域内的两个可用性区（AZ）中分别部署主库和备库。

通过上图可以看到，在高可用方案架构中，托管在 Azure Premium Storage 中的日志文件通过 异地冗余存储（ZRS）提供的存储级同步复制功能复制到备用服务器，就像之前在第一部分中提到的 LRS 同步复制一样。当主节点发生故障导致服务不可用时，主库存储层的日志文件仍可被备库所访问。这意味着备库仍然可以从主库的存储层获取 Binlog 日志来完成 Replay，使 得 Azure MySQL 在故障转移过程中不会丢失数据（RPO=0）。

接下去我们再来看看 RTO。根据第二部分中关于原生主从复制的原理，我们可以很快发现，RTO 时间中最主要的部分是备节点根据 Relay log 进行 Reply 的时长，这很大程度上取决于发生故障转移时主服务器中的事务负载情况和写入压力大小。在 Azure MySQL 自动故障转移过程中，RTO 时间还包含后台监控系统发现主节点的故障时间以及 DNS 切换时间，因为 Azure MySQL 通过 FQDN 来进行连接。后台监控系统会以一定的频率对服务器的状态进行检测，包括底层 VM 状态和 MySQL 服务进程状态两部分。在发现数据库服务器故障后，立即启动自动故障转移过程，同时会在故障转移过程中再次确认主服务器的状态来确认是否要进行回滚以避免瞬间网络抖动等带来的误判。一般来说，整个故障转移的时间通常在 60 秒至 120 秒之 间，对于高性能定价层(High-Performance SKU in private preview)服务器，通过对存储层的进 一步优化，RTO 时间则是在 30 秒至 60 秒之间。