Azure Database for MySQL 中的高可用性

适用于：Azure Database for MySQL - 单一服务器

Azure Database for MySQL 服务提供有保证的高级别可用性，即，提供正常运行时间占比为 99.99% 且具有财务支持的服务级别协议 (SLA)。 Azure Database for MySQL 在发生计划内事件（例如用户发起的缩放计算操作）期间提供高可用性，并且还在发生基础硬件、软件或网络故障等计划外事件时提供高可用性。 Azure Database for MySQL 在发生大多数严重状况时都可以快速恢复，确保用户在使用此服务时应用程序几乎不会停机。

Azure Database for MySQL 适合运行对正常运行时间要求很高的关键数据库。 该服务基于 Azure 体系结构构建，具有固有的高可用性、冗余性和复原能力，可以缓解计划内和计划外中断造成的数据库停机，不需要你配置任何其他组件。

Azure Database for MySQL 中的组件

组件	说明
MySQL 数据库服务器	Azure Database for MySQL 为数据库服务器提供安全性、隔离、资源保护和快速重启功能。 这些功能用于在 60-120 秒内发生中断后辅助操作（例如缩放和数据库服务器恢复操作），具体取决于数据库上的事务活动。 数据库服务器中的数据修改通常发生在数据库事务的上下文中。 所有数据库更改都以预写日志 (ib_log) 的形式同步记录在 Azure 存储上，该存储附加到数据库服务器。 在数据库检查点过程中，数据库服务器内存中的数据页也会刷新到存储中。
远程存储	所有 MySQL 物理数据文件和日志文件都存储在 Azure 存储中，该存储设计为在一个区域中存储数据的三个副本，以确保数据冗余、可用性和可靠性。 存储层还独立于数据库服务器。 它可以在 60 秒内从发生故障的数据库服务器分离并重新附加到新的数据库服务器。 此外，Azure 存储还会持续监视是否存在任何存储故障。 如果检测到块损坏，则会通过实例化新的存储副本来自动修复。
网关	网关充当数据库代理，将所有客户端连接路由到数据库服务器。

缓解计划内停机

Azure Database for MySQL 设计为在计划内停机操作期间提供高可用性。

下面是一些计划内维护方案：

方案	说明
计算纵向扩展/缩减	当用户执行计算纵向扩展/缩减操作时，将使用缩放的计算配置来预配新的数据库服务器。 在旧的数据库服务器中，将允许处于活动状态的检查点完成，客户端连接将排空，所有未提交的事务将取消，然后将关闭该服务器。 然后会从旧数据库服务器分离存储并将其附加到新的数据库服务器。 当客户端应用程序重试连接或尝试建立新连接时，网关会将连接请求定向到新的数据库服务器。
纵向扩展存储	纵向扩展存储是一种联机操作，不会中断数据库服务器。
新软件部署 (Azure)	新功能的推出或 bug 修复作为服务的计划内维护的一部分自动发生。 有关详细信息，请参阅文档并检查你的门户。
次要版本升级	Azure Database for MySQL 会自动将数据库服务器修补到 Azure 确定的次要版本。 这是在服务的计划内维护过程中发生的。 在计划内维护期间，可能会发生数据库服务器重启或故障转移，这可能会导致最终用户的数据库服务器暂时不可用。 Azure Database for MySQL 服务器在容器中运行，因此数据库服务器重启通常很快，预计一般会在 60-120 秒内完成。 工程团队会认真监视包括每个服务器重启在内的整个计划内维护事件。 服务器故障转移时间取决于数据库恢复时间，如果在故障转移时服务器上有大量的事务活动，这可能会导致数据库需要更长的时间才能联机。 若要避免重启时间延长，建议在计划内维护事件期间避免任何长时间运行的事务（大容量加载）。 有关详细信息，请参阅文档并检查你的门户。

缓解计划外停机

意外的故障（包括基础硬件故障、网络问题和软件 bug）可能会导致计划外停机。 如果数据库服务器意外关闭，则会在 60-120 秒内自动预配一个新的数据库服务器。 远程存储会自动附加到新的数据库服务器。 MySQL 引擎使用 WAL 和数据库文件执行恢复操作，并打开数据库服务器以允许客户端进行连接。 未提交的事务将丢失，并且必须由应用程序重试。 虽然计划外停机无法避免，但 Azure Database for MySQL 可以通过在数据库服务器和存储层上自动执行恢复操作来减少停机时间，无需人工干预。

计划外停机：故障场景和服务恢复

下面介绍了一些故障场景以及 Azure Database for MySQL 如何自动恢复：

方案	自动恢复
数据库服务器故障	如果数据库服务器由于某些基础硬件故障而关闭，则会丢弃处于活动状态的连接，并中止任何正在进行的事务。 将自动部署新的数据库服务器，并将远程数据存储附加到新的数据库服务器。 在数据库恢复完成后，客户端可以通过网关连接到新的数据库服务器。 所构建的使用 MySQL 数据库的应用程序需要能够检测并重试丢弃的连接和失败的事务。 当应用程序重试时，网关会将连接透明地重定向到新创建的数据库服务器。
存储故障	对于任何与存储相关的问题（例如磁盘故障或物理块损坏），应用程序看不到任何影响。 由于数据存储在 3 个副本中，因此将由未发生故障的存储提供数据的副本。 块损坏会自动修复。 如果丢失了数据的副本，则会自动创建数据的新副本。

下面是需要用户执行操作来进行恢复的一些故障场景：

方案	恢复计划
区域故障	区域故障非常少见。 但是，如果需要在发生区域故障时获得保护，则可在其他区域中配置一个或多个用于灾难恢复 (DR) 的只读副本。 （请参阅此文，详细了解如何创建和管理只读副本）。 如果出现区域级故障，可以手动将其他区域上配置的只读副本提升为生产数据库服务器。
逻辑/用户错误	在发生用户错误（例如，意外删除了表或错误地更新了数据）后进行的恢复涉及到执行时间点恢复 (PITR)，方法是将数据还原并恢复到发生错误之前的那个时间点。 如果只需还原部分数据库或特定的表，而不是还原数据库服务器中的所有数据库，则可在新实例中还原数据库服务器，通过 mysqldump 导出表，然后使用 restore 将这些表还原到数据库中。

摘要

Azure Database for MySQL 提供了数据库服务器快速重启功能、冗余存储和网关的高效路由。 为了进一步进行数据保护，你可以将备份配置为异地复制的备份，同时在其他区域中部署一个或多个只读副本。 利用固有的高可用性功能，Azure Database for MySQL 保护数据库免受最常见的服务中断影响，并提供行业领先且具有财务支持的正常运行时间占比为 99.99% 的 SLA。 所有这些可用性和可靠性功能使得 Azure 成为运行关键应用程序的理想平台。

后续步骤

• 了解如何处理暂时性连接错误
• 了解如何使用只读副本复制数据