通过

高可用性和灾难恢复清单 - Azure SQL 数据库

  • 项目

适用于：Azure SQL 数据库

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

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

可用性核对清单

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

高可用性清单

下面是实现高可用性的建议配置：

  • 在数据库或弹性池可用的情况下启用区域冗余，以确保在区域故障时具有复原能力。

灾难恢复清单

尽管 Azure SQL 数据库自动维护可用性，但某些实例在具有高可用性（区域冗余）时可能无法保证复原能力，因为受影响的中断会跨越整个区域。 一个区域性的 Azure SQL 数据库在发生中断时可能需要启动灾难恢复。

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

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

为中断准备辅助数据库

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

  • 对于异地还原，标识其他区域中要成为新的主服务器的服务器。 这个服务器通常位于主数据库所在区域的配对区域中。 使用区域中与主服务器配对的服务器可消除异地还原操作期间的额外流量成本。
  • 确定如何将用户重定向到新的主服务器。 重定向用户可以通过手动更改应用程序连接字符串或 DNS 条目来实现。 如果已启用故障转移组并在应用程序连接字符串中使用读写和只读的侦听器，则无需进一步操作，因为故障转移后，会自动定向连接到新的主服务器。
  • 标识（并选择性定义）用户访问新的主数据库时所需的防火墙规则。
  • 标识（并选择性创建）新主服务器的 master 数据库中必须存在的登录名，并确保这些登录名在 master 数据库中具有相应权限（若有）。 有关详细信息，请参阅灾难恢复后的 Azure SQL 数据库安全性。
  • 标识需要更新才能映射到新的主数据库的警报规则。
  • 记录当前主服务器上的审核配置，并在辅助服务器上进行相同的配置。

相关内容