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 刷新日志文件后，确认提交和写入。 由于主副本和备用副本位于同一区域，因此应用程序服务器和数据库服务器之间的复制延迟时间更短。 当依赖基础结构针对特定可用性区域关闭时，同一区域设置不提供高可用性。 在该可用性区域，所有依赖服务都重新联机之前，会停机。
将在主数据库服务器的本地冗余存储上执行自动备份（快照和日志备份）。
注意
对于区域冗余和相同区域高可用性：
- 如果发生故障，备用副本接管主副本角色所需的时间取决于将二进制日志从主存储帐户重播到备用服务器所需的时间。 若要缩短故障转移时间，请对所有表使用主键。 故障转移时间通常需要 60 到 120 秒。
- 备用服务器不可用于读取或写入操作。 备用服务器处于被动待机状态，可实现快速故障转移。
- 始终使用完全限定的域名 (FQDN) 连接到主服务器。 避免使用 IP 地址进行连接。 如果发生故障转移，在切换主服务器和备用服务器角色后，DNS A 记录可能会更改。 如果连接字符串中使用 IP 地址，则此更改可防止应用程序连接到新的主服务器。
故障转移过程
在 Azure Database for MySQL 中的故障转移过程中，系统会自动从主服务器切换到备用副本。 此开关可确保连续性并最大程度地减少停机时间。 当系统检测到故障时，它会将备用副本提升为新的主服务器。 系统将原始主服务器中的二进制日志文件应用到备用副本。 此过程将备用副本与上次提交的事务同步，并确保不会丢失任何数据。 这种无缝转换有助于维护数据库服务的高可用性和可靠性。
计划内事件：强制故障转移
Azure Database for MySQL 灵活服务器强制故障转移使你能够手动强制故障转移。 此功能允许你使用应用程序方案测试功能，并帮助为中断做好准备。
强制故障转移会触发一次故障转移，这会通过更新 DNS 记录将备用副本激活为具有相同数据库服务器名称的主服务器。 原始主服务器重启并切换到备用副本。 客户端连接断开连接，需要重新连接才能恢复其作。
总体故障转移时间取决于当前工作负荷和最后一个检查点。 一般情况下，需要 60 到 120 秒。
注意
在计划的故障转移期间生成 Azure 资源运行状况事件。 该事件表示服务器不可用的故障转移时间。 在左窗格中选择 “资源运行状况 ”时，可以看到触发的事件。 状态表示用户启动或手动故障转移为“不可用”，并标记为“已计划”。 示例 -“故障转移操作由已计划的授权用户触发”。 如果资源长时间处于此状态，请开具 支持票证 ，我们为你提供帮助。
计划外事件：自动故障转移
由于软件 bug 或基础结构故障（例如计算、网络或存储故障），可能会发生计划外服务停机。 停电还会影响数据库的可用性。 如果数据库不可用，则复制到备用副本会停止，备用副本将成为主数据库。 发生 DNS 更新，客户端重新连接到数据库服务器，恢复其作。
总体故障转移时间通常介于 60 到 120 秒之间。 但是，根据故障转移时主数据库服务器中的活动（例如大型事务和恢复时间），故障转移可能需要更长的时间。
注意
在计划外故障转移期间生成 Azure 资源运行状况事件。 该事件表示服务器不可用时的故障转移时间。 在左窗格中选择 “资源运行状况 ”时，可以看到触发的事件。 自动故障转移显示“不可用”状态，并标记为“计划外”。
例如，不可用：自动触发故障转移作（计划外）。 如果资源长时间处于此状态，请开具 支持票证 ，我们为你提供帮助。
自动故障转移检测在已启用 HA 的服务器中的工作原理
主服务器和辅助服务器各有两个网络终结点：
- 客户终结点：客户使用此终结点连接并运行实例上的查询。
- 管理终结点：在内部用于服务通信以管理组件并连接到后端存储。
运行状况监视器组件持续执行以下检查：
- 监视器对节点的管理网络终结点执行 ping作。 如果此检查在一行中失败两次，则会触发自动故障转移作。 此运行状况检查解决了由于 OS 问题、管理组件和节点之间的网络问题以及类似问题而导致节点不可用或无响应等方案。
- 监视器在实例上运行简单的查询。 如果查询无法运行，则自动故障转移触发器。 此运行状况检查解决了 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 复制延迟 | 复制延迟 | 秒 | 复制延迟是备用服务器在重播主服务器收到的事务时滞后的秒数。 |
限制
使用高可用性时，请记住以下注意事项：
只能在创建服务器期间配置区域冗余高可用性。
可突发计算层不支持高可用性。
重启主数据库服务器以应用静态参数更改也会重启备用副本。
解决方案启用 GTID 模式，因为它使用 GTID。 检查工作负载是否对使用 GTID 进行复制有限制。
注意
默认情况下，为配置的高可用性服务器启用了存储自动增长，并且无法禁用。
健康检查
为 Azure Database for MySQL 配置高可用性（HA）时，运行状况检查在维护数据库的可靠性和性能方面起着重要作用。 这些检查会持续监视主副本和备用副本的状态和运行状况，确保它们及时检测到任何问题。 通过跟踪各种指标（例如服务器响应能力、复制滞后时间和资源利用率），运行状况检查有助于确保无缝执行故障转移进程，最大限度地减少停机时间并防止数据丢失。 正确配置的运行状况检查对于在数据库设置中实现所需水平的可用性和复原能力至关重要。
监视运行状况
可以通过 Azure 门户监视 HA 设置的运行状况。 要观察的关键指标包括：
- 服务器响应能力：指示是否可以访问主服务器。
- 复制滞后时间：度量主副本和备用副本之间的延迟，确保数据一致性。
- 资源利用率： 监视 CPU、内存和存储使用情况，以防止瓶颈。