Azure Database for MySQL的可靠性

Azure Database for MySQL是一项完全托管的数据库服务，可让你对数据库管理功能和配置设置进行精细控制和灵活性。 该服务根据要求提供高可用性（HA）和灾难恢复（DR）功能。

使用 Azure 时，可靠性是共同的责任。 Azure提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。

本文介绍如何使Azure Database for MySQL应对各种潜在中断和问题，包括暂时性故障、可用性区域中断、区域中断和服务维护。 它还介绍了如何使用备份从其他类型的问题中恢复，并重点介绍了有关Azure Database for MySQL服务级别协议（SLA）的一些关键信息。

生产部署建议

Azure Well-Architected 框架提供有关可靠性、安全性、成本、作和性能的建议。 若要了解这些领域如何相互影响，并为可靠的Azure Database for MySQL解决方案做出贡献，请参阅Azure Database for MySQL的体系结构最佳做法。

可靠性体系结构概述

本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。

逻辑体系结构

使用 Azure Database for MySQL 时，部署一个 server，表示支持数据库服务器所需的计算和存储资源。 将一个或多个 数据库 部署到服务器。

您可以在突发型、通用型和内存优化 计算层级中部署服务器。 每个计算层 都针对不同类型的工作负荷进行优化。

有关常规服务体系结构和部署模型的详细信息，请参阅Azure Database for MySQL概述。

物理体系结构

  • 计算和存储分离：Azure Database for MySQL使用计算和存储分离体系结构来支持 HA。 数据库引擎在虚拟机（VM）上运行。 数据文件存储在 Azure 存储中，Azure 存储同步维护数据的三个副本，以保护免受存储硬件故障的影响。 根据服务器的 HA 配置，数据文件可以存储在区域冗余存储（ZRS）或本地冗余存储（LRS）中。

  • HA： 可以选择在服务器上启用 HA 配置 。 启用 HA 配置时，服务会预配和维护暖备用副本服务器。 主服务器上的数据更改同步复制到备用副本服务器，以确保主服务器发生故障期间不会丢失任何数据。

    该体系结构将计算层与存储层分开，这样服务就可以适当地处理不同类型的故障。 为了提高复原能力，可以将服务器分散到可用性区域。

    备用副本服务器部署在与主服务器相同的 VM 配置中，包括 vCore、存储和网络设置。

    可以通过执行 故障转移在服务器之间切换。 在主服务器发生故障时使用 计划外故障转移 ，并在需要最大程度地减少故障转移期间的应用程序停机时间时使用 计划内故障转移 。

    有关详细信息，请参阅 Azure Database for MySQL 中的 HA。

  • Backups： Azure Database for MySQL会自动创建服务器备份。 有关详细信息，请参阅 备份和还原。

暂时性故障的复原能力

暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。

与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。

应用程序必须处理在维护、缩放操作或网络中断期间可能发生的暂时性连接错误。 遵循以下建议：

  • 当应用程序遇到暂时性故障时，请使用指数退避重试操作。 增加重试之间的延迟并限制尝试次数。 如果操作在最大重试次数后继续失败，则将其视为失败。

  • 如果可能，请使用自动处理重试的 客户端库 。

  • 在写入操作期间发生的暂时性错误需要仔细考虑。 请考虑将写操作设计为幂等的，以便可以多次执行这些操作。

应对可用区故障的弹性

可用性区域 是 Azure 区域内物理上分开的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。

通过 HA 配置选择可用性区域支持类型。 启用 HA 时，Azure Database for MySQL将备用副本服务器与主服务器一起部署。 此 HA 模型有助于确保提交的数据在失败期间永远不会丢失。 无论选择哪种 HA 部署模型，服务都同步将数据提交到主副本服务器和备用副本服务器。 如果主服务器中断，服务器会自动故障转移到备用副本服务器。

该服务将数据存储在Azure 文件存储高级存储上。 根据服务器的 HA 配置，它使用 ZRS 或 LRS，后者在可用性区域中或跨可用性区域存储三个数据副本。

使用 HA 时，Azure Database for MySQL支持两种可用性区域配置类型：

如果在不使用 HA 的情况下配置服务器，则会在单个服务器上运行。 如果该服务器或其区域发生故障，则服务器不可用。

要求

  • 区域支持：Azure Database for MySQL支持不同的可用性区域配置，具体取决于Azure区域。 有关区域的完整列表（包括可用性区域支持类型以及每个区域的特定注意事项），请参阅Azure区域。

  • 服务层级： HA 需要常规用途或内存优化层。 可突发层不支持 HA（区域冗余或本地冗余）。

Cost

启用 HA 时，可以创建备用服务器并按与主服务器相同的费率付费。 可用性区域配置不会影响成本。 数据复制在可用性区域内或之间不会产生任何费用。 根据备份存储容量，您可能还会被收取备份存储费用。 有关详细的定价信息，请参阅 Azure Database for MySQL 定价。

注意事项

  • 主键： 在所有表上使用主键，因为此方法可减少复制和故障转移时间。

  • 限制和已知问题： 查看 限制 列表和 已知问题。

配置可用性区域支持

若要配置服务器的可用性区域支持，请配置 HA 设置。

注释

选择要使用的可用性区域时，实际上是在选择逻辑可用性区域。 如果在不同的Azure订阅中部署其他工作负荷组件，他们可能会使用不同的逻辑可用性区域编号来访问相同的物理可用性区域。 有关详细信息，请参阅 物理和逻辑可用性区域。

所有区域正常时的行为

本部分介绍在使用 HA 和可用性区域支持配置服务器时的预期情况，并且所有可用性区域都正常运行。

  • 跨区域操作： MySQL 客户端应用程序使用数据库服务器的完全限定域名（FQDN）连接到主服务器。 避免使用主服务器的 IP 地址，因为 IP 地址可能会更改，包括在故障转移期间。

    Azure Database for MySQL使用主动-被动配置，其中主服务器处理主可用性区域中的所有数据库连接和查询。 备用副本服务器在正常操作期间不会为客户端流量提供服务。

  • 跨区域数据复制： 写入操作在主服务器上提交，并使用 ZRS 同步写入备用服务器的日志。 主服务器不会等待备用服务器应用日志，但由于日志位于 ZRS 中，即使发生副本或区域故障，它们也可用。

    复制的影响因服务器使用的可用性区域配置而异：

    • 区域冗余： 由于服务器位于单独的区域中，因此此方法可确保在发生区域故障期间丢失零数据。 这种情况也称为在发生区域故障时达到零的恢复点目标（RPO）。

      但是，跨区域复制可能会带来少量的额外延迟。 平均而言，应用程序写入和提交延迟可能会增加 5% 到 10%，但影响因工作负荷、所选 SKU 和区域而异。

    • 本地冗余： 区域之间不会复制任何流量。

    注释

    系统会将所有更改实时复制到备用副本服务器，其中也包括用户的非故意错误，例如误删表或错误更新数据。 由于直接复制，无法使用备用副本进行恢复。 若要从用户错误中恢复，必须从备份中进行时间点还原。 有关详细信息，请参阅 备份和还原。

区域故障期间的行为

本部分介绍将服务器配置为支持 HA 和可用区时，如果发生可用区故障，可能会出现什么情况。

  • 检测和响应： Azure 定期检查主服务器和备用服务器的运行状况。 多次 ping 后，如果运行状况监视检测到主服务器无法访问，该服务将启动自动故障转移到备用服务器。 健康监测算法使用多个数据点来避免误报事件。

    如果发生区域故障，则行为因服务器使用的可用性区域配置而异：

    • Zone-redundant： Azure Database for MySQL通过持续监视多个服务器终结点自动检测可用性区域故障。 有关详细信息，请参阅 已启用 HA 的服务器中的自动故障转移检测的工作原理。

      若要查看可能的 HA 状态类型，请参阅 “监视 HA”。 当某个区域发生故障时，Azure启动 计划外故障转移，而无需执行操作。

    • 本地冗余： 如果托管本地冗余服务器的可用性区域变得不可用，则主服务器和备用服务器都不可用。 在此方案中，该服务不提供自动故障转移。 你负责检测区域中断和执行恢复操作，例如将区域冗余备份还原到另一个可用性区域或区域中的单独服务器。

  • 通知： Azure 不会在区域关闭时自动通知你。 但是，可以使用 Azure 资源运行状况 监视单个资源的运行状况，并且可以设置 资源运行状况 警报来通知问题。 还可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。

    Azure Database for MySQL 在发生计划外故障转移时，会生成 Azure 资源运行状况 事件。

  • 活动请求： 当可用性区域变得不可用时，对受影响区域中的服务器正在进行的请求可能会终止。 应用程序必须重试这些请求。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。

  • 预期数据丢失： 数据丢失量取决于服务器的可用性区域配置。

    • 区域冗余： 由于不同区域中的主服务器和备用服务器之间的同步复制，区域故障转移期间预计会出现零数据丢失。

    • 本地冗余： 受影响区域中的服务器上的数据在恢复之前不可用。

  • 预期的停机时间： 停机时间量取决于服务器使用的可用性区域配置。

    • 区域冗余： 故障转移通常在 60 至 120 秒内完成。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。

    • 本地冗余： 在可用性区域恢复之前，受影响区域中的服务器不可用。

  • 分配： 流量重新路由行为取决于服务器使用的可用性区域配置。

    • 区域冗余： 故障转移后，备用服务器将成为新的主服务器，并开始接受新的连接。 Azure在恢复后自动在原始主区域中建立备用服务器。 有关详细信息，请参阅 计划外故障转移。

    • 本地冗余： 当某个区域不可用时，服务器不可用。 如果你有一台在另一个可用性区域或区域中预创建的单独服务器，则负责将流量重新路由到该服务器。

区域恢复

区域恢复行为取决于服务器使用的可用性区域配置。

  • 区域冗余：当可用性区域恢复时，Azure Database for MySQL会自动重新生成恢复区域中的备用服务器，并将其与当前主服务器同步。 然后，恢复的区域充当备用位置。 该服务不会自动将主角色移回原始区域，以避免不必要的中断。 如果要将主数据库返回到原始区域，可以 手动启动计划的故障转移。

  • 本地冗余： 区域正常后，区域中的服务器将再次可用。 你负责工作负荷所需的区域恢复过程和数据同步。

测试区域故障

测试区域故障的选项取决于实例使用的可用性区域配置。

对区域范围的故障的复原能力

Azure Database for MySQL支持跨区域只读副本，可用于在不同的区域中维护数据库的同步副本，以便更快地恢复。

还可以在受支持的区域中使用异地冗余备份来提供跨区域恢复。 但是，备份通常涉及比复制更多的停机时间和数据丢失。 有关详细信息，请参阅 备份和还原。

跨区域只读副本

部署只读副本以保护数据库免受区域级故障的影响。 每个只读副本都是单独的 Azure Database for MySQL 服务器。 将只读副本放置在第二个 Azure 区域中时，您的数据库服务器可以提供一个针对区域性问题的复原能力。 最多可以部署 10 个只读副本，这些副本可以选择位于不同的Azure区域中。

MySQL 物理复制技术从主要区域中的源服务器异步更新只读副本，这意味着副本可以滞后于源。 跨区域只读副本可以选择为只读工作负荷提供服务，以减少全局分布式应用程序的延迟或从源服务器卸载读取流量。 有关只读副本功能和注意事项的详细信息，请参阅 只读副本。

显示辅助 Azure 区域中只读副本的示意图，其中应用程序将读写流量导向源服务器。

如果主要区域失败，可以手动故障转移，使辅助副本成为主服务器。 若要手动故障转移，请停止复制过程，将只读副本提升为读写服务器。 由于异步复制，故障转移可能导致数据丢失。 应用程序需要连接到新的主服务器，并负责应用程序重新配置。

此图显示了第二个 Azure 区域中的读取副本，该副本已故障转移并成为主服务器，应用程序现将读写流量定向到辅助区域。

注释

本部分总结了有关只读副本如何支持抵御区域性故障的能力的一些重要信息。 还可以使用 只读副本 来提高性能和支持大规模地理分布式用户群。

要求

  • 区域支持： 可以在支持Azure Database for MySQL的任何区域中创建跨区域只读副本。 你并不限于使用 Azure 的配对区域。

  • 计算层： 常规用途和内存优化计算层支持只读副本。 该可突发层不支持只读副本。

注意事项

  • 配置差异： 创建副本时，它会从源服务器继承多个设置，包括计算生成、vCore 和存储。 可以在创建只读副本后自定义这些值，但最好使用相等或更大的值来确保副本可以跟上源中的更改。

  • 监视复制滞后时间： 异步复制过程需要复制滞后时间，这可能因多种因素而异。 复制滞后时间非常高时，服务器可能会遇到问题。 请务必监视复制延迟，以便在问题恶化之前缓解问题。 有关详细信息，请参阅 “监视复制”。

  • HA： 只读副本不能启用 HA，当它们通过故障转移成为主服务器时，也不会启用 HA。 故障转移到副本后，需要由你负责配置高可用性（HA）。

Cost

读副本会产生计算和存储成本，以及复制的跨区域数据传输费用。 有关详细的定价信息，请参阅 Azure Database for MySQL 定价 和 带宽定价。

配置多区域支持

当所有区域都正常时的行为

本节介绍当您将服务器配置为使用另一个区域中的只读副本，且所有区域均正常运行时，预期会出现的情况：

  • 区域之间的流量路由： 在正常操作期间，应用程序应将读写流量定向到主要区域中的源服务器。 可以选择性地将读取请求定向到读取副本。

  • 区域之间的数据复制： 跨区域只读副本使用异步复制来最大程度地减少对源服务器性能的影响。 复制滞后时间取决于几个因素，包括写入负载和源服务器和副本之间的延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 Monitor 复制，有关详细说明，请参阅 Azure 门户中的 Monitor 复制。

区域故障期间的行为

本节介绍当您将服务器配置为支持跨区域只读副本，且主区域发生中断时，会出现什么情况。

  • 检测和响应： 你负责检测主区域发生的中断，并手动触发故障转移。 此操作可能会导致丢失未复制的数据。

    重要

    你负责触发故障转移。 即使发生区域故障，Azure也不会自动故障转移到只读副本。

    故障转移要求你执行以下步骤：

    1. 停止复制。 此过程不可逆，服务器无法再次转换为副本。 此过程会导致数据丢失。 有关此操作的含义的详细信息，请参阅 “停止复制”。

    2. 将应用程序重新配置为使用新的主服务器。

    有关详细信息，请参阅故障转移。

  • Notification： Azure不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报通知问题。

  • 活动请求： 如果源服务器不可用，则会删除与源区域的所有活动连接。 故障转移过程完成后，应用程序需要重试连接到新的主服务器。

  • 预期数据丢失： 在区域故障期间，必须执行故障转移以停止复制。 此过程会导致永久丢失未复制的数据。

    数据丢失量取决于服务中断时的复制延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。

  • 预期的停机时间： 触发操作后，停止复制通常在两分钟内完成。 你负责将应用程序配置为连接到新的主服务器。 你执行重新配置所需的时间也会计入总停机时间。

  • 流量重新路由： 你负责将应用程序配置为连接到新的主服务器。

    注释

    将只读副本故障转移为主服务器后，该服务器未启用高可用性 (HA)。 必须手动启用 HA 或将其包含在自动化中。

区域恢复

当区域恢复时，你负责故障回复活动以恢复主要区域中的操作。 Azure不会自动移动主服务器。 可以在主要区域中创建一个新的只读副本，然后执行另一次故障转移过程，以恢复主要区域中的操作。 请考虑以下方法之一，具体取决于应用程序是否可以容忍停机或数据丢失：

  • 将应用程序下线，并等待复制完成对所有更改的同步。 此方法需要与复制滞后时间大致相同的应用程序停机时间。

  • 执行故障转移并接受未复制数据丢失的后果。

请记住，你还负责将应用程序配置为根据需要连接到新的主服务器。

针对区域故障进行测试

定期测试只读副本故障转移过程，以确保进程有效且功能满足恢复时间目标（RTO）和 RPO 要求。

可以故障转移只读副本，以随时成为主服务器，即使所有区域都正常。 建议在非生产环境中执行这些测试，因为它可能会导致数据丢失，并且需要手动故障回复。

作为 DR 策略的一部分，定期运行完整恢复演练。 这些演练包括数据验证、应用程序功能测试和记录的回滚过程。

备份和还原

Azure Database for MySQL自动备份数据，因此你可以将其还原到备份保留期内的任何时间点。 此保护有助于避免意外损坏和删除数据。 Azure完全管理备份，而不会中断服务器的可用性。 备份包括完整备份和事务日志备份。

  • 备份存储： 如果使用区域冗余 HA 配置服务器，系统会将备份存储在 ZRS 中。 对于在没有 HA 或本地冗余 HA 的情况下配置的服务器，系统会将备份存储在 LRS 中。

    在具有对的Azure区域中，可以在创建服务器时为备份配置异地冗余存储（GRS）。 此方法将备份复制到Azure配对区域，以便针对区域故障提供额外的保护。 系统以异步方式复制备份。

    默认备份保留期为 7 天，但可将保留期延长至 35 天。 所有备份均已加密。

  • 恢复： 时间点还原（PITR）允许将数据库还原到备份保留期内的任何时刻。 还原过程使用新的用户提供的服务器名称创建新的数据库服务器。 可以使用新服务器 as-is 或从中复制数据。

    还原异地冗余备份时，将在配对区域中创建新的服务器。 在某些区域，可以使用 Universal Geo-Restore 将异地冗余备份还原到不是主要区域配对的其他区域。

    使用此功能可从意外的数据修改、应用程序错误或测试方案中恢复。

对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。

有关详细信息，请参阅 在 Azure Database for MySQL 中的备份和还原。

服务维护期间的系统弹性能力

Azure Database for MySQL自动处理关键服务任务，包括修补基础硬件、操作系统和数据库引擎。 该服务包括安全更新、软件更新和次要版本升级，作为计划内维护的一部分。 有关详细信息，请参阅 Azure Database for MySQL 中的 计划维护。

若要确保服务器在维护时段内保持可用状态，请遵循以下建议：

  • 避免在维护期间执行管理操作。 在进行维护时不要执行服务器管理操作，因为这些操作可能会影响服务器的可靠性。

  • 采用近乎零停机维护。 如果服务器已启用 HA 并满足其他资格条件，则维护操作通常在 10 到 30 秒内完成。 如果启用 HA，维护操作通常使用滚动更新来最大程度地减少停机时间。 定期维护操作（如次要版本升级）会先在备用副本上进行。 为了减少停机时间，备用服务器将提升为主服务器，以便在剩余节点上应用维护任务时工作负荷可以继续运行。 无论服务器使用区域冗余还是本地冗余 HA，此排序都适用。 有关详细信息，请参阅 近零停机时间维护。

  • 配置自定义维护时段。 可以将维护计划配置为系统管理，或定义自定义维护时段，以最大程度地减少对业务运营的影响。 还可以重新安排计划内的维护操作。 在低活动期间计划维护，以最大程度地减少业务影响。 有关详细信息，请参阅 管理 Azure Database for MySQL 的计划维护设置。

  • 实现重试逻辑。 确保应用程序可以处理维护重启期间可能发生的短暂连接中断。 为了使您的应用程序能够应对这类问题，请参阅对暂时性故障的抵抗能力。

  • 在开发和测试服务器上启用 Virtual Canary 维护。 虚拟 Canary 维护可抢先获取更新。 通过在开发和测试服务器上启用它，可以验证即将进行的更新在到达生产服务器之前不会影响工作负荷。 有关更多信息，请参见虚拟金丝雀维护。

服务级别协议

Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。

Azure Database for MySQL根据服务器的配置提供不同的可用性 SLA：

  • 配置有区域冗余 HA 的服务器。
  • 配置有本地冗余 HA 的服务器。
  • 未配置 HA 的服务器。

相关内容

  • Last updated on