通过

高可用性和灾难恢复清单 - Azure SQL 托管实例

  • 项目

适用于：Azure SQL 托管实例

Azure SQL 托管实例服务会自动确保所有数据库都处于联机状态、正常运行，并不断努力达到已发布的 SLA。

本指南详细回顾了可以采取的主动步骤，以便最大程度地提高可用性、确保恢复并为 Azure 中断做好准备。 本指南适用于 Azure SQL 托管实例的所有服务层。

可用性核对清单

下面是建议的配置，以最大程度地提高可用性：

灾难恢复清单

尽管 Azure SQL 托管实例会自动维护可用性，但在某些情况下，即使具有高可用性也可能无法保证复原能力，因为受影响的中断可能跨越整个区域。 一个区域性的 Azure SQL 托管实例如果中断可能需要启动灾难恢复。

若要为灾难恢复做好最佳准备，请遵循以下建议：

  • 为实例启用故障转移组。
    • 在应用程序连接字符串中使用读写和只读侦听器终结点以便应用程序自动连接到主实例。
    • 将故障转移策略设置为 客户托管。
  • 确保使用与主实例相同的服务层、硬件生成和计算大小创建异地辅助实例。
  • 在纵向扩展时，扩展异地辅助数据库，然后再扩展主数据库。
  • 纵向缩减时，则按相反顺序进行：先缩减主数据库，再缩减辅助数据库。
  • 灾难恢复本质上旨在利用主要区域和次要区域之间的异步数据复制。 若要让数据可用性优先于更高的提交延迟，请考虑在提交事务后立即调用 sp_wait_for_database_copy_sync 存储过程。 调用 sp_wait_for_database_copy_sync 会阻止调用线程，直到最后提交的事务已传输并强制执行到辅助数据库的事务日志中。
  • 使用主数据库上 sys.dm_geo_replication_link_status 动态管理视图 (DMV) 的 replication_lag_sec 列，监视与恢复点目标 (RPO) 相关的延迟。 DMV 显示主数据库上提交的事务与强制执行到辅助数据库上的事务日志的事务之间的滞后时间（以秒为单位）。 例如，如果主数据库在该时间点受到中断的影响，并且启动了异地故障转移，则在上一秒提交的事务将丢失。
  • 如果无法启用故障转移组，请考虑将备份存储冗余选项设置为异地冗余备份存储以使用异地还原功能。
  • 经常计划和执行灾难恢复演练，以便在发生实际服务中断时做好更充分的准备。

为中断准备辅助数据库

若要使用故障转移组或异地还原成功恢复到另一个数据区域，需要在另一个区域中准备辅助 Azure SQL 托管实例。 如果需要，此辅助实例可以成为新的主实例。 还应记录并测试明确定义的步骤，以确保顺利恢复。 准备步骤包括：

  • 对于异地还原，标识其他区域中要成为新的主实例的实例。 该实例通常是主实例所在区域的配对区域中的实例。 使用与主区域配对的区域中的实例可消除异地还原操作期间的额外流量成本。
  • 确定如何将用户重定向到新的主服务器。 重定向用户可以通过手动更改应用程序连接字符串或 DNS 条目来实现。 如果已启用故障转移组并在应用程序连接字符串中使用读写和只读的侦听器，则无需进一步操作，因为故障转移后，会自动定向连接到新的主服务器。
  • 确定并根据需要定义 NSG 和路由表配置，用户需要访问新主实例的新主数据库。
  • 标识（并选择性创建）新主服务器的 master 数据库中必须存在的登录名，并确保这些登录名在 master 数据库中具有相应权限（若有）。
  • 记录当前主实例上的审核配置 ，并使它与辅助实例上的配置相同。

相关内容

若要了解详细信息，请查看：