共计 2152 个字符，预计需要花费 6 分钟才能阅读完成。
数据库是整个 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 秒之间。