Azure Database for MySQL 灵活服务器中的高可用性概念

适用于： Azure Database for MySQL 灵活服务器

Azure Database for MySQL 灵活服务器支持为高可用性配置自动故障转移。 高可用性解决方案旨在确保提交的数据永远不会由于故障而丢失，且数据库不会成为软件体系结构中的单一故障点。 配置高可用性后，灵活服务器会自动预配和管理备用副本。 我们将对主要副本和次要副本的预配计算和存储计费。 有两种高可用性体系结构模型：

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

• 相同区域高可用性。 要实现网络延迟较低的基础结构冗余，此选项是首选选项，因为主服务器和备用服务器将位于同一可用性区域中。 它提供高可用性，且无需跨区域配置应用程序冗余。 如果希望在网络延迟最低的单个可用性区域中实现最高级别可用性，则首选相同区域高可用性。 相同区域高可用性在所有 Azure 区域中可用，在这些区域中可以使用 Azure Database for MySQL 灵活服务器。

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

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

• 一个主服务器在一个可用性区域中。
• 一个备用副本服务器，位于同一 Azure 区域的另一个可用区中，与主服务器具有相同配置（计算层级、计算大小、存储大小和网络配置）。

可以选择主要副本和备用副本的可用性区域。 将备用数据库服务器和备用应用程序放在同一区域中可降低延迟。 这样还能更好地准备灾难恢复情况和“区域关闭”方案。

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

如果存在故障转移：

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

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

数据库服务器名称用于将应用程序连接到主服务器。 不会公开备用副本信息以供直接访问。 在主服务器的 ZRS 刷新日志文件后，确认提交和写入。 由于 ZRS 存储中使用的是同步复制技术，应用程序的写入和提交延迟可能会增加 5% 到 10%。

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

同区域高可用性体系结构

部署具有同一区域高可用性的服务器时，将在同一区域中创建两台服务器：

• 主服务器
• 一个备用副本服务器，与主服务器具有相同配置（计算层级、计算大小、存储大小和网络配置）

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

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

如果存在故障转移：

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

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

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

将在主数据库服务器的本地冗余存储上执行自动备份（快照和日志备份）。

故障转移过程

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

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

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

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

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

计划外服务停机可能由软件 bug 或基础架构故障（如计算、网络或存储故障）或影响数据库可用性的停电引起。 如果数据库变得不可用，则到备用副本的复制将被切断，备用副本将被激活为主数据库。 DNS 更新，然后客户端可重新连接到数据库服务器并恢复操作。

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

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

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

• 客户终结点：客户使用此终结点在实例上连接并运行查询。
• 管理终结点：在内部用于服务通信以管理组件并连接到后端存储。

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

• 监视器对节点管理网络终结点执行 ping 操作。 如果此检查连续两次失败，则会触发自动故障转移操作。 此运行状况检查可解决由于 OS 问题、管理组件和节点之间的网络问题等而导致的节点不可用/无响应等情况。
• 监视器还会对实例运行简单的查询。 如果查询未能运行，将触发自动故障转移。 此运行状况检查可解决 MySQL 守护程序崩溃/停止/挂起、后端存储问题等情况。

监视高可用性

门户中服务器的“高可用性”窗格中的高可用性状态可用于确定服务器的 HA 配置状态。

还可以使用以下指标来监视 HA 服务器的运行状况。

限制

在使用高可用性时，请注意以下几项注意事项：

• 只有在创建灵活服务器时才能设置区域冗余高可用性。
• 可突增计算层级不支持高可用性。
• 如果重启主数据库服务器以获取静态参数更改，也会重启备用副本。
• 将开启 GTID 模式，因为高可用性解决方案使用 GTID。 检查工作负载是否对使用 GTID 进行复制有限制。

常见问题 (FAQ)

• 高可用性 (HA) 服务器如何计费？ 启用高可用性的服务器具有主要副本和次要副本。 次要副本可以位于同一区域或区域冗余。 我们将对主要副本和次要副本的预配计算和存储计费。 例如，如果主要副本有 4 个 vCore 的计算和 512 GB 的预配存储，则次要副本也会有 4 个 vCore 和 512 GB 的预配存储。 区域冗余 HA 服务器将按 8 个 vCore 和 1024 GB 存储计费。 根据备份存储卷，还可能会对备份存储计费。

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

• 发生故障转移时，是否会丢失数据？
  即使在主服务器不可用时，也可访问 ZRS 中的日志。 这种可用性有助于确保数据不会丢失。 激活备用副本并应用二进制日志后，它将采用主服务器的角色。
  

• 故障转移后是否需要采取任何措施？
  故障转移对客户端应用程序是完全透明的。 你不必执行任何操作。 应用程序应该只对其连接使用重试逻辑。
  

• 不为备用副本选择特定区域时会发生什么情况？ 以后能否更改区域？
  如果未选择区域，则系统会随机选择一个区域。 将用于主服务器。 若要稍后更改区域，可以在“高可用性”窗格中将“高可用性”设置为“禁用”，然后将其重新设置为“区域冗余”并选择一个区域。
  

• 主服务器和备用副本之间的复制是否同步？
  主服务器与备用服务器之间的复制类似于 MySQL 中的半同步模式。 提交事务时，不一定要将事务提交到备用服务器。 但是当主服务器不可用时，备用服务器会从主服务器复制所有数据更改，以确保没有数据丢失。
  

• 对于所有计划外故障，是否故障转移到备用副本？
  如果数据库崩溃或节点发生故障，将首先将在同一节点上重启灵活服务器 VM。 同时，将触发自动故障转移。 如果在故障转移完成之前灵活服务器 VM 重启成功，则会取消故障转移操作。 确定将哪个服务器用作主要副本取决于首先完成的过程。
  

• 使用高可用性时是否会影响性能？
  对于区域冗余高可用性，虽然对跨可用性区域的读取工作负载没有重大性能影响，但写入查询延迟可能会下降高达 40%。 写入延迟的增加是由于跨可用性区域进行同步复制导致的。 区域冗余高可用性中的写入延迟影响通常是同区域高可用性中的两倍。 对于同区域高可用性，由于主要副本和备用副本在同一可用区中，因此复制延迟和同步写入延迟较低。 总之，如果与可用性相比，写入延迟对你而言更为重要，你可能希望选择同区域高可用性，但如果数据的可用性和复原能力更为重要，那么你必须选择区域冗余高可用性，代价是写入延迟下降。 若要评估高可用性设置中延迟下降的准确影响，建议为工作负载执行性能测试，以做出明智的决策。
  

• 高可用性服务器的维护如何发生？
  调整计算规模和次要版本升级等计划事件首先在原始备用实例上发生，然后触发计划的故障转移操作，之后再对原始主实例进行操作。 可以为高可用性服务器设置定期维护窗口，就像你为灵活服务器设置的那样。 停机时间与禁用高可用性时 Azure Database for MySQL 灵活服务器实例的停机时间相同。
  

• 能否在高可用性服务器执行时间点还原 (PITR)？
  你可以为启用了高可用性的 Azure Database for MySQL 灵活的服务器实例执行 PITR，将其还原到禁用了高可用性的新 Azure Database for MySQL 灵活服务器实例。 如果源服务器是使用区域冗余高可用性创建的，则可以稍后在还原的服务器上启用区域冗余高可用性或相同区域高可用性。 如果使用相同区域高可用性创建了源服务器，则只能在还原的服务器上启用相同的区域。
  

• 创建服务器后，是否可以在服务器上启用高可用性？
  创建服务器时需要启用区域冗余高可用性。 可以在创建服务器后启用同域高可用性。 启用“相同区域高可用性”之前，请确保将服务器参数“enforce_gtid_consistency”和“gtid_mode”设置为 ON
  

• 在创建服务器之后，可以禁用高可用性吗？
  在创建服务器之后可以在服务器上禁用高可用性。 计费将立即停止。
  

• 如何减少停机时间？
  即使不使用高可用性，也需要能够减少应用程序的停机时间。 可以在预定维护窗口期间执行服务停机时间（如预定补丁、次要版本升级）或客户启动的操作（如计算扩展）。 为了减轻 Azure 启动的维护任务对应用程序的影响，可以将它们安排在一周中的某一天和时间，以最大限度地减少对应用程序的影响。
  

• 可以将只读副本用于支持高可用性的服务器吗？
  可以，高可用性服务器支持只读副本。
  

• 能否将数据传入复制用于高可用性服务器？
  只有通过基于 GTID 的复制，才能支持已启用高可用性 (HA) 的服务器的数据传入复制。 使用 GTID 进行复制的存储过程在所有已启用 HA 的服务器上均可用，其名称为 mysql.az_replication_with_gtid。

• 为了减少停机时间，我可以在服务器重新启动期间或在纵向扩展或横向缩减时故障转移到备用服务器吗？
  目前，Azure Database for MySQL 灵活服务器已使用计划内故障转移来优化高可用性操作（包括纵向扩展/缩减和计划内维护），以帮助减少停机时间。 当此类操作启动时，它将首先对原始备用实例进行操作，然后触发计划的故障转移操作，之后再对原始主实例进行操作。
  

• 是否可更改服务器的可用性模式（区域冗余 HA/同域）
  如果创建的服务器启用了区域冗余高可用性模式，则可将区域冗余高可用性更改为同域高可用性，反之亦然。 若要更改可用性模式，可以在“高可用性”窗格中将“高可用性”设置为“禁用”，然后将其重新设置为“区域冗余”或“同域”并选择“高可用性模式”。
  

后续步骤

• 了解业务连续性。
• 了解区域冗余高可用性。
• 了解备份和恢复。