你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for MySQL是一项完全托管的数据库服务，旨在提供对数据库管理功能和配置设置的精细控制和灵活性。 该服务根据要求提供高可用性和灾难恢复功能。
使用 Azure 时，可靠性是共同的责任。 Microsoft提供了一系列功能来支持复原和恢复。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍如何使Azure Database for MySQL应对各种潜在的中断和问题，包括暂时性故障、可用性区域中断、区域中断和服务维护。 它还介绍了如何使用备份从其他类型的问题中恢复，并重点介绍了有关Azure Database for MySQL服务级别协议（SLA）的一些关键信息。
生产部署建议
若要了解如何部署 Azure Database for MySQL 以支持解决方案的可靠性要求，以及可靠性如何影响架构的其他方面，请参阅 Azure Well-Architected Framework 中的《Azure Database for MySQL 体系结构最佳实践》。
可靠性体系结构概述
本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。
逻辑体系结构
使用 Azure Database for MySQL 时，部署一个 server，表示支持数据库服务器所需的计算和存储资源。 将一个或多个 数据库 部署到服务器。
可以在多个 计算层中部署服务器：可突发、常规用途和内存优化，每个服务器 都针对不同类型的工作负荷进行优化。
有关常规服务体系结构和部署模型的详细信息，请参阅 什么是 Azure Database for MySQL？。
物理体系结构
Compute 和存储分离： Azure Database for MySQL使用计算和存储分离体系结构来支持高可用性。 数据库引擎在虚拟机上运行。 数据文件存储在 Azure 存储中，Azure 存储同步维护数据的三个副本，以保护免受存储硬件故障的影响。 根据服务器的高可用性配置，数据文件可以存储在区域冗余存储（ZRS）或本地冗余存储（LRS）中。
高可用性： 可以选择在服务器上启用 高可用性配置 。 启用高可用性配置时，服务会预配和维护暖备用副本服务器。 主服务器上的数据更改同步复制到备用副本服务器，以确保主服务器发生故障期间不会丢失任何数据。
该体系结构将计算层与存储层分开，使服务能够适当地处理不同类型的故障。 为了提高复原能力，可以将服务器分散到可用性区域。
备用副本服务器部署在与主服务器相同的 VM 配置中，包括 vCore、存储和网络设置。
可以通过执行 故障转移在服务器之间切换。 有两种类型的故障转移： 计划外故障转移（在主服务器发生故障时使用）和 计划内故障转移，这些故障转移用于需要在故障转移期间最大程度地减少应用程序停机时间的其他方案。
有关详细信息，请参阅 Azure Database for MySQL 中的 高可用性。
Backups： Azure Database for MySQL会自动创建服务器备份。 有关详细信息，请参阅 备份和还原。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循Azure暂时性故障处理指南。 有关详细信息，请参阅 处理暂时性故障的建议。
应用程序必须处理在维护、缩放操作或网络中断期间可能发生的暂时性连接错误。 遵循以下建议：
- 当应用程序遇到暂时性故障时，请使用指数退避重试操作。 增加重试之间的延迟并限制尝试次数。 如果操作在最大重试后仍然失败，则将其视为失败。
- 尽可能使用自动处理重试的 客户端库 。
- 在写入操作期间发生的暂时性错误需要仔细考虑。 请考虑使写入操作成为幂等的，以确保能够安全地多次执行。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上分开的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
可以通过 高可用性 配置选择可用性区域支持的类型。 启用高可用性会将 备用副本服务器 与主服务器一起部署。 此高可用性模型有助于确保提交的数据在失败期间永远不会丢失。 无论选择哪种高可用性部署模型，数据都同步提交到主副本服务器和备用副本服务器。 如果主服务器发生中断，服务器会自动切换到备用服务器。
数据存储在Azure 文件存储高级存储上。 根据服务器的高可用性配置，它使用区域冗余存储或本地冗余存储（LRS），后者在可用性区域中或跨可用性区域存储三个数据副本。
使用高可用性时，Azure Database for MySQL支持两种可用性区域配置类型：
区域冗余高可用性： 区域冗余通过在不同的可用性区域中部署主服务器和备用副本服务器来提供最高级别的区域复原能力。 备用副本服务器使用与主服务器类似的计算、存储和网络配置。 区域冗余配置会在主服务器和备用服务器之间为整个堆栈提供物理隔离。
您为主服务器和备用服务器选择可用性区域。
建议为生产服务器部署区域冗余部署。
写入操作在提交延迟方面可能会略有增加，因为服务会同步将数据复制到备用服务器。 平均而言，应用程序写入和提交延迟会增加 5-10%，但影响因工作负荷、所选 SKU 和区域而异。
本地冗余高可用性： 主服务器和备用服务器使用相同的可用性区域。 如果主服务器发生中断，而区域仍然健康，则服务器会自动切换到备用服务器。
本地冗余部署提供单个可用性区域中的高可用性。 它可以保护你免受节点级故障的影响，还有助于在计划内和计划外停机事件期间减少应用程序停机时间。 但是，它不会防止该区域出现中断。 在具有可用性区域的区域中，此类配置有时也称为区域或单区域。
建议仅在特定方案中实现本地冗余高可用性：
- 如果你有异常延迟敏感的应用程序，那么你已验证了需要将主要副本和次要副本之间的延迟降到最低，并通过使用其他体系结构方法，您已自行计划实现区域复原。
- 部署到不支持可用性区域的区域时，该区域实际上充当单个区域，使本地冗余高可用性成为唯一的高可用性选项。
由于服务器位于同一区域，因此可以减少在该区域中部署的应用程序的写入延迟。
如果在没有高可用性的情况下配置服务器，则会在单个服务器上运行。 如果该服务器或其区域出现故障，则服务器不可用。
要求
区域支持： Azure Database for MySQL对可用性区域配置的支持因Azure区域而异。 有关区域的完整列表以及可用性区域支持类型以及该区域的任何特定注意事项，请参阅 Azure 区域。
服务层级： 高可用性需要常规用途或内存优化层。 可突发层不支持高可用性（区域冗余或本地冗余）。
Cost
启用高可用性时，将创建备用服务器，并按与主服务器相同的费率计费。 可用性区域配置不会影响成本。 可用性区域中或可用性区域之间的数据复制不收取任何费用。 根据备份存储容量，您可能还会被收取备份存储费用。 有关详细的定价信息，请参阅 Azure Database for MySQL 定价。
注意事项
配置可用性区域支持
若要为服务器配置可用性区域支持，请配置高可用性设置。
注释
选择要使用的可用性区域时，实际上是在选择逻辑可用性区域。 如果在不同的Azure订阅中部署其他工作负荷组件，他们可能会使用不同的逻辑可用性区域编号来访问相同的物理可用性区域。 有关详细信息，请参阅 物理和逻辑可用性区域。
创建区域冗余服务器： 若要了解如何创建启用了高可用性和区域冗余的服务器，请参阅：
- Azure门户：使用 Azure 门户在Azure Database for MySQL中实现区域冗余高可用性
- Azure CLI：使用 Azure CLI 在 Azure Database for MySQL 中管理区域冗余高可用性
创建本地冗余服务器：若要在单个可用性区域中创建具有本地冗余高可用性的服务器，必须使用 Azure CLI 或其他编程部署方法。 有关Azure CLI说明，请参阅在创建服务器期间实现高可用性。
更改现有服务器的可用性区域配置： 如果有现有服务器，则启用可用性区域支持的方法取决于服务器的初始配置。
若要将现有服务器更改为区域冗余的高可用性，需要迁移到新服务器。 有关详细信息，请参阅 从现有服务器迁移到区域冗余服务器。
若要将现有服务器更改为本地冗余高可用性，请执行以下操作：
- 禁用高可用性（如果已启用）。
- 启用本地冗余高可用性。 必须使用Azure CLI或其他编程部署方法。 有关 Azure CLI 的说明，请参阅 使用 Azure CLI 管理 Azure Database for MySQL 中的区域冗余高可用性。
禁用高可用性： 禁用高可用性会删除备用副本服务器，因此服务器无法复原到区域级服务中断。 但是，如果启用了异地冗余备份，则服务器仍可以使用这些备份在不同的区域中恢复。 有关详细信息，请参阅 “禁用高可用性”。
所有区域正常时的行为
本部分介绍在服务器配置了高可用性和可用区支持且所有可用区均正常运行时的预期情况。
跨区域操作： MySQL 客户端应用程序使用数据库服务器的完全限定域名（FQDN）连接到主服务器。 避免使用主服务器的 IP 地址，因为 IP 地址可能会更改，包括在故障转移期间。
Azure Database for MySQL使用主动/被动配置，其中所有数据库连接和查询都由主可用性区域中的主服务器处理。 备用副本服务器在正常操作期间不会为客户端流量提供服务。
跨区域数据复制： 写入在主服务器上提交，并使用 ZRS 同步写入备用服务器的日志。 主服务器不会等待备用服务器应用日志，但由于日志位于 ZRS 中，即使发生副本或区域故障，它们也可用。
复制的影响因服务器使用的可用性区域配置而异：
区域冗余： 由于服务器位于单独的区域中，因此此方法可确保在发生区域故障期间丢失零数据。 这种情况也称为在发生区域故障时达到零的恢复点目标（RPO）。
但是，跨区域复制可能会带来少量的额外延迟。 平均而言，应用程序写入和提交延迟会增加 5-10%，但影响因工作负荷、所选 SKU 和区域而异。
本地冗余：在各个区域之间不进行任何流量复制。
注释
系统将实时的所有更改复制到备用副本服务器，包括意外删除表或不正确的数据更新等意外用户错误。 由于直接复制，无法使用备用副本进行恢复。 若要从用户错误中恢复，必须从备份中进行时间点还原。 有关详细信息，请参阅 备份和还原。
区域故障期间的行为
本部分介绍当服务器配置了高可用性和可用性区域支持，并且出现可用性区域中断时应期待的情况。
检测和响应： Azure 定期检查主服务器和备用服务器的运行状况。 多次 ping 后，如果运行状况监视检测到主服务器无法访问，该服务将启动自动故障转移到备用服务器。 健康监测算法使用多个数据点来避免误报事件。
发生区域故障时，行为因服务器使用的可用性区域配置而异：
Zone-redundant： Azure Database for MySQL通过持续监视多个服务器终结点自动检测可用性区域故障。 有关详细信息，请参阅 已启用 HA 的服务器中的自动故障转移检测的工作原理。
若要查看可能的高可用性状态类型，请参阅 “监视高可用性”。 当某个区域发生故障时，Azure启动 计划外故障转移，而无需执行操作。
本地冗余： 如果托管本地冗余服务器的可用性区域变得不可用，则主服务器和备用服务器都不可用。 在此方案中，该服务不提供自动故障转移。 你负责检测区域中断和执行恢复操作，例如将区域冗余备份还原到另一个可用性区域或区域中的单独服务器。
Notification：当区域关闭时，Microsoft不会自动通知你。 但是，可以使用 Azure 资源运行状况 监视单个资源的运行状况，并且可以设置 资源运行状况 警报来通知问题。 还可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。
Azure Database for MySQL 在发生计划外故障转移时，会生成 Azure 资源运行状况 事件。
活动请求： 当可用性区域变得不可用时，可能会终止对受影响区域中服务器的任何正在进行的请求。 应用程序必须重试这些请求。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
预期数据丢失： 数据丢失量取决于服务器的可用性区域配置。
区域冗余： 由于不同区域中的主服务器和备用服务器之间的同步复制，区域故障转移期间预计会出现零数据丢失。
本地冗余： 受影响区域中的服务器上的数据在恢复之前不可用。
预期的停机时间： 停机时间量取决于服务器使用的可用性区域配置。
区域冗余： 故障转移通常在 60-120 秒内完成。 如果客户在短时间内重试，以适当处理暂时性故障，通常可以避免重大影响。
本地冗余： 在可用性区域恢复之前，受影响区域中的服务器不可用。
分配： 流量重新路由行为取决于服务器使用的可用性区域配置。
区域冗余： 故障转移后，以前的备用服务器将成为新的主服务器，并开始接受新连接。 Azure在恢复后自动在原始主区域中建立备用服务器。 有关详细信息，请参阅 计划外故障转移。
本地冗余： 当某个区域不可用时，服务器不可用。 如果你有一台在另一个可用性区域或区域中预创建的单独服务器，则负责将流量重新路由到该服务器。
区域恢复
区域恢复行为取决于服务器使用的可用性区域配置。
区域冗余：当可用性区域恢复时，Azure Database for MySQL会自动重新生成恢复区域中的备用服务器，并将其与当前主服务器同步。 然后，恢复的区域充当备用位置。 该服务不会自动将主角色移回原始区域，以避免不必要的中断。 如果您希望将主数据库返回到原始区域，可以手动启动计划内故障转移。
本地冗余： 区域正常后，区域中的服务器将再次可用。 你负责工作负荷所需的任何区域恢复过程和数据同步。
测试区域故障
测试区域故障的选项取决于实例使用的可用性区域配置。
区域冗余： 可以通过启动计划的故障转移来测试应用程序的故障转移复原能力。 通过计划内故障转移，您可以在运行工作负载时模拟未计划的停机事件，并观察应用程序的停机时间。 建议在非生产环境中或在安静时间运行模拟。 有关详细信息，请参阅 计划的故障转移。
本地冗余： 虽然无法模拟整个区域中断，但可以模拟服务器不可用的方式与区域中断期间发生的情况类似。 有关详细信息，请参见:
- Azure 门户：停止/启动 Azure Database for MySQL 灵活服务器实例
- Azure CLI：重启/停止/启动 Azure 数据库 for MySQL - 灵活服务器实例
对区域范围的故障的复原能力
Azure Database for MySQL支持 跨区域只读副本，可用于在跨不同区域中维护数据库的同步副本，以便实现更快速的恢复。
还可以在受支持的区域中使用异地冗余备份来提供跨区域恢复。 但是，备份通常涉及比复制更多的停机时间和数据丢失。 有关详细信息，请参阅 备份和还原。
跨区域只读副本
可以部署只读副本来保护数据库免受区域级故障的影响。 每个只读副本都是单独的 Azure Database for MySQL 服务器。 将只读副本放置在第二个 Azure 区域中时，您的数据库服务器可以提供一个针对区域性问题的复原能力。 最多可以部署 10 个只读副本，这些副本可以选择位于不同的Azure区域中。 MySQL 的物理复制技术会从主要区域中的源服务器异步更新只读副本，并且它们可能会滞后于源。 跨区域只读副本可以选择为只读工作负荷提供服务，以减少全局分布式应用程序的延迟或从源服务器卸载读取流量。 如需详细了解只读副本的功能和注意事项，请参阅只读副本。
如果主区域发生故障，可以手动进行故障切换，使次要副本成为主服务器。 为此，您可以通过停止复制过程，将只读副本转换为读写服务器。 由于异步复制，故障转移可能导致数据丢失。 然后，应用程序需要连接到新的主服务器，并负责此应用程序重新配置。
注释
本部分总结了有关只读副本如何支持抵御区域性故障的能力的一些重要信息。 还可以使用只读副本来提高性能和支持大规模地理分布式用户群。 有关详细信息，请参阅 只读副本。
要求
区域支持： 可以在支持Azure Database for MySQL的任何区域中创建跨区域只读副本。 您不必仅限于 Azure 配对区域。
计算层： 常规用途和内存优化计算层支持只读副本。 该可突发层不支持只读副本。
注意事项
配置差异： 创建副本时，它会从源服务器继承多个设置，包括计算生成、vCore 和存储。 可以在创建只读副本后自定义这些值。 但是，最好使用相等或更大的值以确保副本能够跟上源代码中的更改。
监视复制滞后时间： 异步复制过程需要复制滞后时间，具体取决于多种因素。 复制滞后时间非常高时，服务器可能会遇到问题。 请务必监视复制延迟，以便在问题恶化之前缓解问题。 有关详细信息，请参阅 “监视复制”。
高可用性： 只读副本无法启用高可用性，即使在切换为主服务器时，也不会具备高可用性。 你负责在切换到副本后配置高可用性。
Cost
读副本会产生计算和存储成本，以及复制的跨区域数据传输费用。 有关详细的定价信息，请参阅 Azure Database for MySQL 定价 和 带宽定价。
配置多区域支持
创建只读副本： 若要了解如何创建只读副本，请参阅：
- Azure门户：如何使用 Azure 门户在 Azure Database for MySQL - 灵活服务器中创建和管理只读副本
- Azure CLI：如何使用 Azure CLI 在 Azure Database for MySQL - 灵活服务器中创建和管理只读副本
创建源服务器后，可以配置副本，前提是源服务器正在运行且可访问。
停止复制： 若要了解如何停止复制，请参阅 停止复制到副本服务器。
删除只读副本： 若要了解如何删除只读副本，请参阅 “删除副本服务器”。
当所有区域都正常时的行为
本节介绍当您的服务器配置了位于另一个区域的只读副本，并且所有区域均正常运行时，可以预期的情况。
区域之间的流量路由： 在正常操作中，应用程序应将读写流量定向到主要区域中的源服务器。 可以选择性地将读取请求定向到读取副本。
区域之间的数据复制： 跨区域只读副本使用异步复制来最大程度地减少对源服务器性能的影响。 复制滞后时间取决于多种因素，包括写入负载和源服务器与副本之间的延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 Monitor 复制，有关详细说明，请参阅 Azure 门户中的 Monitor 复制。
区域故障期间的行为
在另一地区配置了只读副本的服务器，而主要地区发生中断时，本部分介绍您可以期待的情况：
检测和响应： 你负责检测主要区域中的故障，并手动触发故障转移。 此操作可能会导致丢失任何未复制的数据。
重要
你负责触发故障转移。 即使发生区域故障，Azure也不会自动故障转移到只读副本。
故障转移要求您：
- 停止复制。 这是一个不可逆的过程，服务器不能再次成为副本。 此过程会导致数据丢失。 有关此操作含义的更多详细信息，请参阅 “停止复制”。
- 将应用重新配置为使用新的主服务器。
有关详细信息，请参阅故障转移。
Notification： Microsoft不会在区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 了解服务的总体运行状况，包括任何区域故障，并且可以设置 Service Health 警报来通知问题。
活动请求： 如果源服务器不可用，则会删除与源区域的所有活动连接。 故障转移过程完成后，应用程序需要重试连接到新的主服务器。
预期数据丢失： 在区域故障期间，必须执行故障转移以停止复制。 此过程会导致任何未复制的数据永久丢失。
数据丢失量取决于服务中断时的复制延迟。 复制滞后时间通常至少为几分钟，但可能更长。 有关详细信息，请参阅 “监视复制”。
预期的停机时间： 停止复制通常在触发后的 2 分钟内完成。 你负责重新配置应用程序以连接到新的主服务器，执行重新配置所需的时间也会导致整个停机时间。
流量重新路由： 你负责将应用程序配置为连接到新的主服务器。
注释
在故障转移只读副本为主服务器后，该服务器没有启用高可用性功能。 必须手动启用高可用性，或将其包含在自动化中。
区域恢复
当区域恢复时，你负责任何故障回复活动以恢复主要区域中的操作。 Microsoft不会自动移动主服务器。 可以在主要区域中创建一个新的只读副本，然后执行另一次故障转移过程，以恢复主要区域中的操作。 请考虑以下方法之一，具体取决于应用程序是否可以容忍停机或数据丢失：
- 将您的应用程序下线，并等待复制过程赶上所有的更改。 此方法需要应用程序停机，大致等于复制滞后时间。
- 执行故障转移并接受丢失任何未复制的数据。
请记住，你还负责重新配置应用程序以根据需要连接到新的主服务器。
针对区域故障进行测试
定期测试只读副本故障转移过程，以确保进程有效，并且这些功能满足 RTO 和 RPO 要求。
可以故障转移只读副本，以随时成为主服务器，即使所有区域都正常。 建议在非生产环境中执行这些测试，因为它可能会导致数据丢失，并且需要手动回退。
作为灾难恢复策略的一部分，定期运行完整恢复演练。 这些演练应包括数据验证、应用程序功能测试和记录的回滚过程。
备份和还原
Azure Database for MySQL自动执行备份，这些备份提供时间点恢复功能，并帮助防止意外损坏和删除数据。 Microsoft完全管理备份，不要中断服务器的可用性，并包括完整备份和事务日志备份。
备份存储： 如果服务器配置了区域冗余高可用性，备份将存储在区域冗余存储（ZRS）中。 对于未配置高可用性或具有本地冗余高可用性的服务器，备份存储在本地冗余存储（LRS） 中。
在具有对的Azure区域中，可以在服务器创建时配置异地冗余（GRS）备份存储，以便将备份复制到Azure配对区域，以便防止区域故障。 备份以异步方式复制。
默认备份保留期为 7 天，此选项可将保留期延长至 35 天。 所有备份均已加密。
恢复： 时间点恢复允许将数据库还原到备份保留期内的任何时刻。 还原过程使用新的用户提供的服务器名称创建新的数据库服务器，然后可以使用 as-is 或从中复制数据。
还原异地冗余备份时，将在配对区域中创建新的服务器。 在某些区域，可以使用 Universal Geo-Restore 将异地冗余备份还原到不是主要区域配对的其他区域。
此功能可用于从意外的数据修改、应用程序错误或测试方案中恢复。
对于大多数解决方案，不应只依赖于备份。 请改用本指南中所述的其他功能来支持复原要求。 但是，备份可以防范其他方法没有的一些风险。 有关详细信息，请参阅什么是冗余、复制和备份？。
有关详细信息，请参阅 在 Azure Database for MySQL 中的备份和还原。
服务维护期间的系统弹性能力
Azure Database for MySQL自动处理关键服务任务，包括修补基础硬件、操作系统和数据库引擎。 该服务包括安全更新、软件更新和次要版本升级，作为计划内维护的一部分。 有关详细信息，请参阅 Azure Database for MySQL 中的 计划维护。
若要确保服务器在维护时段内保持可用状态，请遵循以下建议：
避免在维护期间执行管理操作： 在进行维护时不要执行服务器管理操作，因为这些操作可能会影响服务器的可靠性。
使用近乎零的停机时间维护： 如果服务器已启用高可用性并满足其他资格条件，维护操作通常会在 10-30 秒内完成。 如果已启用高可用性，维护操作通常使用滚动更新来最大程度地减少停机时间。 定期维护活动（例如次要版本升级）首先在备用副本上发生。 为了减少停机时间，将备用节点提升为主节点，以确保在剩余节点进行维护任务时，工作负载可以继续运行。 此顺序适用于无论服务器是使用区域冗余还是本地冗余高可用性。 有关详细信息，请参阅 近零停机时间维护。
配置自定义维护时段： 可以将维护计划配置为系统管理，或定义自定义维护时段，以最大程度地减少对业务运营的影响。 还可以重新安排计划内的维护操作。 在低活动期间计划维护，以最大程度地减少业务影响。 有关详细信息，请参阅 管理 Azure Database for MySQL 的计划维护设置。
实现重试逻辑： 确保应用程序可以处理维护重启期间可能发生的短暂连接中断。 若要使应用程序能够复原这些类型的问题，请参阅 “暂时性故障复原” 指南。
在开发和测试服务器上启用虚拟 Canary 维护： 虚拟 Canary 系统的维护使您能够提前获取更新。 通过在开发和测试服务器上启用它，可以验证工作负荷在到达生产服务器之前是否不受即将更新的影响。 有关更多信息，请参见虚拟金丝雀维护。
服务级别协议
Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 SLa for 联机服务。
Azure Database for MySQL根据服务器的配置提供不同的可用性 SLA：
- 配置有区域冗余高可用性的服务器。
- 配置有本地冗余高可用性的服务器。
- 未配置高可用性的服务器。
相关内容
- Azure可靠性
- Azure 数据库 for MySQL 的架构最佳实践
使用 Azure Database for MySQL 实现业务连续性概述