通过使用 Azure Database for MySQL Flexible Server，您可以配置高可用性，并具备自动故障转移功能。 此解决方案确保在出现故障时，不会导致已提交数据的丢失，并且数据库也不会成为软件架构中的单一故障点。 配置高可用性时，灵活服务器会自动预配和管理备用副本。 为主要副本和辅助副本支付所预配的计算和存储费用。 有两种高可用性体系结构模型：

区域冗余高可用性 。 此选项提供跨多个可用区的基础设施的完全隔离和冗余性。 它提供最高级别的可用性，但需要你配置跨区域的应用程序冗余。 如果要防范可用性区域中的任何基础结构故障，以及可用性区域中的延迟可接受时，请选择区域冗余高可用性。 只能在创建服务器时启用区域冗余高可用性。 区域冗余高可用性在 部分 Azure 区域 可用，这些区域支持多个 可用性区域 并提供 区域冗余高级文件共享 。

本地冗余高可用性 。 此选项提供网络延迟较低的基础结构冗余，因为主服务器和备用服务器将位于同一可用性区域中。 它提供高可用性，无需跨区域配置应用程序冗余。 如果要在具有最低网络延迟的单个可用性区域中实现最高级别的可用性，请选择本地冗余高可用性。 本地冗余高可用性适用于所有 Azure 区域 ，可在其中使用Azure Database for MySQL灵活服务器。

区域冗余高可用性 (HA) 体系结构

部署具有区域冗余高可用性的服务器时，Azure创建两个服务器：

一个主服务器在一个可用性区域中。

位于同一Azure区域的另一个可用性区域中的备用副本服务器。 备用副本服务器的配置与主服务器相同，包括计算层、计算大小、storage大小和网络配置。

可以为主服务器和备用副本选择可用性区域。 将主服务器和备用服务器置于同一区域可降低延迟，而将它们放置在不同的区域中有助于为灾难恢复情况和区域关闭方案做好准备。

数据和日志文件托管在 区域冗余存储 (ZRS) 。 备用服务器从主服务器的storage帐户持续读取和重播日志文件，storage级复制可以保护这些日志文件。

如果发生故障转移，请执行以下操作：

备用副本将激活。

主服务器的二进制日志文件继续应用于备用服务器，使其联机到主服务器上最后提交的事务。

即使在主服务器不可用时，也可访问 ZRS 中的日志。 这种可用性有助于确保数据不会丢失。 激活备用副本并应用二进制日志后，当前备用副本服务器将承担主服务器的角色。 DNS 更新，以确保客户端连接在重新连接时指向新的主服务器。 故障转移在客户端应用程序中是完全透明的，你无需进行任何操作。 然后，高可用性解决方案会尽可能恢复旧的主服务器，并将其安置为备用服务器。

数据库服务器名称用于将应用程序连接到主服务器。 该解决方案不会暴露用于直接访问的备用副本信息。 在主服务器的 ZRS 刷新日志文件后，确认提交和写入。 由于 ZRS storage中使用的同步复制技术，因此应用程序写入和提交延迟会增加 5-10%。

主数据库服务器会自动在区域冗余存储上的备份快照和日志备份。

本地冗余高可用性 （HA） 体系结构

使用本地冗余 HA 部署服务器时，在同一区域中创建两个服务器：

与主服务器具有相同配置的备用副本服务器（计算层、计算大小、storage大小和网络配置）

备用服务器使用单独的虚拟机（计算）提供基础结构冗余。 由于共置，这种冗余减少了应用程序和数据库服务器之间的故障转移时间和网络延迟。

数据和日志文件托管在 本地冗余存储（LRS） 中。 备用服务器持续从主服务器的存储帐户读取并重播日志文件，该帐户受存储级复制的保护。

如果发生故障转移，请执行以下操作：

备用副本将激活。

主服务器的二进制日志文件继续应用于备用服务器，使其联机到主服务器上最后提交的事务。

即使在主服务器不可用时，也可访问 LRS 中的日志。 这种可用性有助于确保数据不会丢失。 当前备用副本激活并应用二进制日志后，将担任主服务器的角色。 当客户端重新连接时，将更新 DNS 以将连接重定向到新的主副本。 故障转移在客户端应用程序中是完全透明的，你无需进行任何操作。 然后，高可用性解决方案会尽可能恢复旧的主服务器，并将其安置为备用服务器。

数据库服务器名称将应用程序连接到主服务器。 备用副本信息不会公开用于直接访问。 在主服务器的 LRS 刷新日志文件后，确认提交和写入。 由于主副本和备用副本位于同一区域，因此应用程序服务器和数据库服务器之间的复制延迟时间更短。 当依赖基础结构针对特定可用性区域关闭时，本地冗余设置不提供高可用性。 在该可用区的所有相关服务重新联机之前，将会有停机时间。

主数据库服务器会自动将快照和日志备份储存到本地冗余存储。

对于区域冗余和本地冗余 HA：

如果出现故障，备用副本接管主副本的角色所需的时间取决于将二进制日志从主存储帐户重播到备用服务器所需的时间。 若要缩短故障转移时间，请对所有表使用主键。 故障转移时间通常在 60 到 120 秒之间。

备用服务器不可用于读取或写入操作。 备用服务器处于被动待机状态，可实现快速故障转移。

始终使用完全限定的域名 (FQDN) 连接到主服务器。 避免使用 IP 地址进行连接。 如果发生故障转移，则在主服务器角色和备用服务器角色切换后，DNS A 记录可能会更改。 如果连接字符串中使用 IP 地址，则此更改会阻止应用程序连接到新的主服务器。

从现有服务器迁移到区域冗余服务器

如果最初将Azure Database for MySQL服务器预配为非 HA 服务器，则可以将其启用本地冗余 HA 体系结构。 但是，如果要为区域冗余 HA 体系结构启用它，则需要使用所需的配置创建新的服务器，并按照以下步骤迁移到该服务器：

按照首选部署工具的说明，创建启用了区域冗余高可用性的新服务器：

Azure门户： 使用 Azure 门户在Azure Database for MySQL中实现区域冗余高可用性

Azure CLI： 通过 Azure CLI 在 Azure Database for MySQL 中管理区域冗余的高可用性

按照以下方法之一将工作负荷迁移到新服务器。 根据迁移方法，可能需要停机。

脱机迁移方法： 如果应用程序可以承受一些停机时间，脱机迁移始终是首选选择，因为它们简单且易于执行。 脱机迁移后，源服务器处于脱机状态，并在目标服务器上执行数据库的转储和还原。 此选项需要最多停机时间。 停机时间的持续时间取决于在目标服务器上执行还原所需的时间。

Data Migration Service （DMS）： 若要了解如何使用 DMS，请参阅 通过 Azure 门户使用 DMS 将 MySQL 脱机迁移至 Azure Database for MySQL 。

尽管本教程概述了从本地 MySQL 服务器迁移到Azure Database for MySQL的步骤，但可以使用相同的过程将数据从不支持可用性区域的一台Azure Database for MySQL服务器迁移到另一台支持可用性区域的服务器。

开源工具： 可以使用开源工具（如 MySQL Workbench 、 mydumper/myloader 或 mysqldump ）脱机迁移，以备份和还原数据库。 有关如何使用这些工具的信息，请参阅 Options，了解如何将 Azure Database for MySQL - 单一服务器迁移到灵活服务器 。 尽管本教程概述了从 Azure MySQL 单一服务器迁移到灵活服务器的步骤，但你可以使用相同的过程将数据从一台不支持可用性区域的Azure Database for MySQL灵活服务器迁移到另一个支持可用性区域的灵活服务器。

联机迁移方法： 联机迁移可最大程度地减少应用程序停机时间。 源服务器允许更新，迁移解决方案将复制源服务器和目标服务器之间的持续更改，以及目标上的初始转储和还原。 但是，这些方法比脱机迁移更为复杂。

Data Migration Service （DMS）： 若要了解如何使用 DMS，请参阅 使用 DMS 通过 Azure 门户在线将 MySQL 迁移到 Azure Database for MySQL 。

尽管本教程概述了从本地 MySQL 服务器迁移到Azure Database for MySQL的步骤，但可以使用相同的过程将数据从不支持可用性区域的一台Azure Database for MySQL服务器迁移到另一台支持可用性区域的服务器。

开源工具： 可以将开源工具（如 mydumper/myloader） 与 数据传入复制 结合使用。

故障转移过程

在Azure Database for MySQL中的故障转移过程中，系统会自动从主服务器切换到备用副本。 以确保连续性并最大程度减少停机时间。 当系统检测到故障时，它会将备用副本提升为新的主服务器。 系统将原始主服务器中的二进制日志文件应用到备用副本。 此过程将备用副本与最后提交的事务同步并确保不会丢失数据。 这种无缝转换有助于维护数据库服务的高可用性和可靠性。

为了减少对 DNS 缓存的故障转移时间依赖关系，从 2025 年 10 月开始，所有通过公共访问或私有链接创建的新高可用服务器都将采用为每台高可用性服务器配备专用 SLB 的新架构。 通过管理 MySQL 数据流量路径，SLB 无需在故障转移期间更改 DNS，并显著提高故障转移性能。 它使用负载均衡规则在故障转移期间将流量重定向到当前主实例。 具有公共访问或私有链接的现有服务器正在逐步迁移，以最大程度地减少影响。 首选早期迁移的客户可以禁用并重新启用高可用性。 在 VNet 集成中使用专用access的服务器不支持此功能。

计划内事件：强制故障转移

Azure Database for MySQL 灵活服务器强制故障转移使你能够手动强制故障转移。 此功能可用于测试应用程序方案的功能，并有助于你为服务中断做好准备。

强制故障转移触发故障转移，通过使用相同的数据库服务器名称并更新 DNS 记录，将备用副本激活为主服务器。 原始主服务器重启并切换到备用副本。 客户端连接断开，需要重新连接才能恢复操作。

总体故障转移时间取决于当前工作负荷和最后一个检查点。 一般情况下，需要 60 到 120 秒。

系统会在计划的故障转移期间生成 Azure 资源运行状况事件。 该事件表示服务器不可用的故障转移时间。 在左窗格中选择 资源运行状况 时，可以看到触发的事件。 状态将用户启动或手动故障转移表示为“不可用”并标记为“计划内”。 例如， 故障转移操作由授权用户触发（计划内） 。 如果资源长时间处于此状态，请开具 支持工单 ，我们将为你提供帮助。

计划外事件：自动故障转移

由于软件错误或基础结构故障（例如计算、网络或存储故障），可能会出现计划外服务停机。 断电也会影响数据库的可用性。 如果数据库变得不可用，则到备用副本的复制将停止，备用副本将变为主数据库。 发生 DNS 更新，客户端重新连接到数据库服务器并恢复操作。

总体故障转移时间通常在 60 到 120 秒之间。 不过，根据发生故障转移时主数据库服务器中的活动（例如大型事务和恢复时间），故障转移可能需要更长时间。

计划外故障转移会生成资源运行状况事件。 该事件表示服务器不可用时的故障转移时间。 在左窗格中选择 资源运行状况 时，可以看到触发的事件。 自动故障转移显示 “不可用” 状态，并标记为 “非计划” 。

例如， 不可用 ：自动触发了故障转移操作（ 非计划的 ）。 如果资源长时间处于这种状态，请开立 支持工单 ，我们会为你提供帮助。

自动故障转移检测在已启用 HA 的服务器中的工作原理

主服务器和辅助服务器各有两个网络终结点：

客户终结点：客户使用此终结点连接实例并在实例上运行查询。

管理终结点：在内部用于服务通信与管理组件，并连接到后端存储。

运行状况监视器组件持续执行以下检查：

监视器对节点的管理网络终结点执行 ping 操作。 如果此检查连续两次失败，则会触发自动故障转移操作。 此运行状况检查用于解决因 OS 问题、管理组件与节点之间的网络问题及类似问题导致的节点不可用或无响应的情况。

监视器会对实例运行简单的查询。 如果查询运行失败，则会触发自动故障转移。 此健康检查解决了 MySQL 守护程序崩溃、停止或挂起，以及后端存储问题和类似问题等情形。

运行状况检查不会监视应用程序与客户网络终结点（私有/公共访问）之间的网络问题。 这些问题可能发生在网络路径、终结点上或客户端的 DNS 问题中。 如果使用专用访问，请确保虚拟网络的 NSG 规则不会阻止与端口 3306 上的实例客户网络端点的通信。 对于公用访问，请确保已设置防火墙规则，并允许端口 3306 上的网络流量（如果网络路径中存在其他防火墙）。 还需要从客户端应用程序端处理 DNS 解析。

监视高可用性

若要检查服务器的高可用性配置状态，请使用门户中服务器高可用性窗格中的 高可用性 状态 。

Azure Database for MySQL 灵活服务器在后端使用本机 MySQL 复制。 MySQL Community Edition 8.0 及更高版本中存在一个已知问题，在执行依赖于 ON DELETE CASCADE 外键约束的多表 DELETE 操作时，可能会中断复制。 此问题跟踪为 MySQL Bug 102586 。 因此，在 Azure Database for MySQL Flexible Server 上启用高可用性功能时，请避免对外键使用级联删除操作，因为此模式可能会导致复制失败，并可能影响服务器的可用性。

为Azure Database for MySQL配置高可用性（HA）时，运行状况检查在维护数据库的可靠性和性能方面发挥了重要作用。 这些检查会持续监视主副本和备用副本的状态和运行状况，确保它们及时检测到任何问题。 通过跟踪各种指标（例如服务器响应能力、复制滞后时间和资源利用率），运行状况检查有助于确保无缝执行故障转移进程，最大限度地减少停机时间并防止数据丢失。 正确配置的运行状况检查对于在数据库设置中实现所需水平的可用性和复原能力至关重要。

监视运行状况

可以通过Azure门户监视 HA 设置的运行状况。 要观察的关键指标包括：

服务器响应能力：指示是否可以访问主服务器 。

复制滞后时间：度量主副本和备用副本之间的延迟，确保数据一致性 。

资源利用率： 监视 CPU、内存和storage使用情况，以防止瓶颈。

可靠性和复原能力

有关 Azure Database for MySQL 中可靠性的全面概述，包括暂时性故障处理、可用性区域复原、具有只读副本的跨区域灾难恢复、备份和还原和服务维护，请参阅 Azure Database for MySQL 的可靠性 。

Azure Database for MySQL 中的高可用性（HA）常见问题（常见问题解答） 有关使用 Azure Database for MySQL 灵活服务器确保业务连续性的概述 Azure Database for MySQL 中的可靠性