你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
Azure Database for MySQL 灵活服务器允许使用自动故障转移配置高可用性。 此解决方案确保在出现故障时，不会导致已提交数据的丢失，并且数据库也不会成为软件架构中的单一故障点。 配置高可用性后，灵活服务器会自动预配和管理备用副本。 需要为主要副本和次要副本支付预配的计算和存储费用。 有两种高可用性体系结构模型：
区域冗余高可用性。 此选项可跨多个可用性区域实现基础结构完全隔离和冗余。 它提供最高级别的可用性，但需要你配置跨区域的应用程序冗余。 当你希望防范可用性区域内的任何基础结构故障，并且可以接受可用性区域之间的延迟时，请选择区域冗余高可用性 (HA)。 只能在创建服务器时启用区域冗余 HA。 区域冗余高可用性在部分 Azure 区域中可用，这些地理区域支持多个可用性区域并且提供区域冗余高级文件共享。
本地冗余高可用性。 此选项提供网络延迟较低的基础结构冗余，因为主服务器和备用服务器将位于同一可用性区域中。 它提供高可用性，且无需跨区域配置应用程序冗余。 如果要在具有最低网络延迟的单个可用性区域中实现最高级别的可用性，请选择本地冗余 HA。 本地冗余高可用性在所有 Azure 区域中可用，在这些区域中可以使用 Azure Database for MySQL - 灵活服务器。
区域冗余高可用性 (HA) 体系结构
部署具有区域冗余高可用性的服务器时，Azure 会创建两个服务器：
- 一个主服务器在一个可用性区域中。
- 同一 Azure 区域的另一个可用性区域中的备用副本服务器。 备用副本服务器与主服务器具有相同配置，包括计算层级、计算大小、存储大小和网络配置。
可以为主服务器和备用副本选择可用性区域。 将备用数据库服务器和备用应用程序放在同一区域中可降低延迟。 这样还能更好地准备灾难恢复情况和“区域故障”方案。
数据和日志文件托管在区域冗余存储 (ZRS)。 备用服务器从主服务器的存储帐户连续读取并重播日志文件，该存储帐户受存储级复制的保护。
如果发生故障转移，请执行以下操作：
- 备用副本将激活。
- 主服务器的二进制日志文件继续应用于备用服务器，使其联机到主服务器上最后提交的事务。
即使在主服务器不可用时，也可访问 ZRS 中的日志。 这种可用性有助于确保数据不会丢失。 激活备用副本并应用二进制日志后，当前备用副本服务器将承担主服务器的角色。 更新 DNS，以便在客户端重新连接时将客户端连接定向到新的主副本。 故障转移在客户端应用程序中是完全透明的，你无需进行任何操作。 然后，高可用性解决方案会尽可能恢复旧的主服务器，并将其安置为备用服务器。
数据库服务器名称用于将应用程序连接到主服务器。 该解决方案不会公开备用副本信息以供随机存取。 在主服务器的 ZRS 刷新日志文件后，确认提交和写入。 由于 ZRS 存储中使用的是同步复制技术，应用程序的写入和提交延迟可能会增加 5% 到 10%。
将在主数据库服务器的区域冗余存储上执行自动备份（快照和日志备份）。
本地冗余高可用性 （HA） 体系结构
使用本地冗余 HA 部署服务器时，在同一区域中创建两个服务器：
- 主服务器
- 一个备用副本服务器，与主服务器具有相同配置（计算层级、计算大小、存储大小和网络配置）
备用服务器通过单独的虚拟机（计算）提供基础架构冗余。 由于共置，这种冗余减少了应用程序和数据库服务器之间的故障转移时间和网络延迟。
数据和日志文件托管在本地冗余存储 (LRS)。 备用服务器从主服务器的存储帐户连续读取并重播日志文件，该存储帐户受存储级复制的保护。
如果发生故障转移，请执行以下操作：
- 备用副本将激活。
- 主服务器的二进制日志文件继续应用于备用服务器，使其联机到主服务器上最后提交的事务。
即使在主服务器不可用时，也可访问 LRS 中的日志。 这种可用性有助于确保数据不会丢失。 激活备用副本并应用二进制日志后，当前备用副本将承担主服务器的角色。 当客户端重新连接时，将更新 DNS 以将连接重定向到新的主副本。 故障转移在客户端应用程序中是完全透明的，你无需进行任何操作。 然后，高可用性解决方案会尽可能恢复旧的主服务器，并将其安置为备用服务器。
数据库服务器名称将应用程序连接到主服务器。 不会公开备用副本信息以供直接访问。 在主服务器的 LRS 刷新日志文件后，确认提交和写入。 由于主副本和备用副本位于同一区域，因此应用程序服务器和数据库服务器之间的复制延迟时间更短。 当依赖基础结构针对特定可用性区域关闭时，本地冗余设置不提供高可用性。 在该可用区的所有相关服务重新联机之前，将会有停机时间。
将在主数据库服务器的本地冗余存储上执行自动备份（快照和日志备份）。
注意
对于区域冗余 HA 和本地冗余 HA：
- 如果出现故障，备用副本接管主副本的角色所需的时间取决于将二进制日志从主存储帐户重播到备用服务器所需的时间。 若要缩短故障转移时间，请对所有表使用主键。 故障转移时间通常在 60 到 120 秒之间。
- 备用服务器不可用于读取或写入操作。 备用服务器处于被动待机状态，可实现快速故障转移。
- 始终使用完全限定的域名 (FQDN) 连接到主服务器。 避免使用 IP 地址进行连接。 如果发生故障转移，则在主服务器角色和备用服务器角色切换后，DNS A 记录可能会更改。 如果在连接字符串中使用了 IP 地址，则该更改将阻止应用程序连接到新的主服务器。
故障转移过程
在 Azure Database for MySQL 中的故障转移过程中，系统会自动从主服务器切换到备用副本， 以确保连续性并最大程度减少停机时间。 当系统检测到故障时，它会将备用副本提升为新的主服务器。 系统将原始主服务器中的二进制日志文件应用到备用副本。 此过程将备用副本与最后提交的事务同步并确保不会丢失数据。 这种无缝转换有助于维护数据库服务的高可用性和可靠性。
计划内事件：强制故障转移
Azure Database for MySQL 灵活服务器强制故障转移使你能够手动强制故障转移。 此功能可用于测试应用程序方案的功能，并有助于你为服务中断做好准备。
强制故障转移会触发一次故障转移，这会通过更新 DNS 记录将备用副本激活为具有相同数据库服务器名称的主服务器。 原始主服务器重启并切换到备用副本。 客户端连接断开，需要重新连接才能恢复操作。
总体故障转移时间取决于当前工作负荷和最后一个检查点。 一般情况下，需要 60 到 120 秒。
注意
系统会在计划的故障转移期间生成 Azure 资源运行状况事件。 该事件表示服务器不可用的故障转移时间。 选择左窗格中的“资源运行状况”时，可以看到触发的事件。 该状态表示用户发起或手动故障转移为“不可用”，并被标记为“计划中”。 示例 -“故障转移操作由已计划的授权用户触发”。 如果资源长时间处于此状态，请开具支持工单，我们将为你提供帮助。
计划外事件：自动故障转移
由于软件错误或基础结构故障（例如计算、网络或存储故障），可能会发生计划外服务停机。 断电也会影响数据库的可用性。 如果数据库变得不可用，则到备用副本的复制将停止，备用副本将变为主数据库。 发生 DNS 更新，客户端重新连接到数据库服务器并恢复操作。
总体故障转移时间通常在 60 到 120 秒之间。 不过，根据发生故障转移时主数据库服务器中的活动（例如大型事务和恢复时间），故障转移可能需要更长时间。
注意
系统会在计划外的故障转移期间生成 Azure 资源运行状况事件。 该事件表示服务器不可用时的故障转移时间。 选择左窗格中的“资源运行状况”时，可以看到触发的事件。 自动故障转移显示状态为“不可用”，并标记为“计划外”。
示例 - 不可用：自动触发故障转移操作（计划外）。 如果资源长时间处于这种状态，请开立支持工单，我们会为你提供帮助。
自动故障转移检测在已启用 HA 的服务器中的工作原理
主服务器和辅助服务器各有两个网络终结点：
- 客户终结点：客户使用此终结点连接实例并在实例上运行查询。
- 管理终结点：在内部用于服务通信以管理组件并连接到后端存储。
运行状况监视器组件持续执行以下检查：
- 监视器对节点管理网络终结点执行 ping 操作。 如果此检查连续两次失败，则会触发自动故障转移操作。 此运行状况检查解决了由于操作系统问题导致的节点不可用或无响应、管理组件和节点之间的网络问题以及类似问题等情况。
- 监视器会对实例运行简单的查询。 如果查询运行失败，则会触发自动故障转移。 此运行状况检查解决了诸如 MySQL 守护进程崩溃、停止或挂起以及后端存储问题等问题。
注意
运行状况检查不会监视应用程序与客户网络终结点（专用/公开访问）之间的网络问题。 这些问题可能发生在网络路径、终结点或客户端的 DNS 问题中。 如果使用专用访问，请确保虚拟网络的 NSG 规则不会阻止与端口 3306 上的实例客户网络终结点的通信。 对于公共访问，请确保在端口 3306（如果网络路径具有任何其他防火墙）上设置防火墙规则，并且允许网络流量。 还需要从客户端应用程序端处理 DNS 解析。
监视高可用性
若要检查服务器的高可用性配置状态，请使用门户中服务器的高可用性窗格中的高可用性状态。
| 状态 | 说明 |
|---|---|
| NotEnabled | 未启用高可用性。 |
| ReplicatingData | 在高可用性服务器配置期间或启用高可用性选项时，备用服务器与主服务器同步。 |
| FailingOver | 数据库服务器正在从主服务器故障转移到备用服务器。 |
| Healthy | 已启用高可用性选项。 |
| RemovingStandby | 禁用高可用性选项时，正在执行删除过程。 |
若要监视高可用性服务器的运行状况，请使用以下指标。
| 指标显示名称 | 指标 | 单位 | 说明 |
|---|---|---|---|
HA IO 状态 |
ha_io_running | 状态 | HA IO 状态显示 HA 复制的状态。 如果 I/O 线程正在运行，则指标值为 1，否则为 0。 |
| HA SQL 状态 | ha_sql_running | 状态 | HA SQL 状态显示 HA 复制的状态。 如果 SQL 线程正在运行，则指标值为 1，否则为 0。 |
| HA 复制延迟 | replication_lag | 秒 | 复制延迟是备用服务器在重播主服务器收到的事务时滞后的秒数。 |
限制
使用高可用性时，请记住以下注意事项：
只能在创建服务器期间配置区域冗余高可用性。
可突发计算层不支持高可用性。
如果重启主数据库服务器以应用静态参数更改，也会重启备用副本。
解决方案启用 GTID 模式，因为它使用 GTID。 检查工作负载是否对使用 GTID 进行复制有限制。
注意
存储自动增长默认为已配置高可用性的服务器启用，无法禁用。
运行状况检查
为 Azure Database for MySQL 配置高可用性 (HA) 时，运行状况检查在维护数据库的可靠性和性能方面发挥着至关重要的作用。 这些检查会持续监视主副本和备用副本的状态和运行状况，确保及时检测到任何问题。 通过跟踪各种指标（例如服务器响应能力、复制滞后时间和资源利用率），运行状况检查有助于确保无缝执行故障转移流程，最大限度减少停机时间并防止数据丢失。 正确配置的运行状况检查对于在数据库设置中实现所需水平的可用性和复原能力至关重要。
监视运行状况
你可以通过 Azure 门户监视其 HA 设置的运行状况。 要观察的关键指标包括：
- 服务器响应能力：指示是否可以访问主服务器。
- 复制滞后时间：度量主副本和备用副本之间的延迟，确保数据一致性。
- 资源利用率：监视 CPU、内存和存储使用情况，以防止出现瓶颈。