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会阻塞调用线程，直到最后提交的事务已传输并固化到辅助数据库的事务日志中。 - 使用主数据库上
replication_lag_sec动态管理视图 (DMV) 的 列，监视与恢复点目标 (RPO) 相关的延迟。 DMV 显示主数据库上已提交事务与辅助数据库上事务日志中已固化事务之间的延迟时间（以秒为单位）。 例如，假设在某一时刻的延迟为一秒，如果主数据库在该时间点受到中断的影响，并且启动了异地故障转移，则在上一秒提交的事务将丢失。 - 如果无法启用故障转移组或活动异地复制，请考虑将备份存储冗余选项设置为“异地冗余备份存储”，以使用 Azure SQL 数据库的异地还原。
- 此选项在没有区域对的区域中不可用。
- 经常计划和执行灾难恢复演练，以便在发生实际服务中断时做好更充分的准备。
若要使用活动异地复制、故障转移组或异地还原成功恢复到另一个数据区域，需要在另一个区域中准备辅助 Azure SQL 数据库逻辑服务器。 如果需要，此辅助服务器可以成为新的主服务器。 还应记录并测试明确定义的步骤，以确保顺利恢复。 准备步骤包括：
- 对于异地还原，请标识另一个区域中的服务器以成为新的主服务器。 如果主要区域具有配对区域，则通常使用配对区域作为次要区域。 通过执行此操作，复制和异地还原操作的延迟通常会降低。
- 确定如何将用户重定向到新的主服务器。 重定向用户可以通过手动更改应用程序连接字符串或 DNS 条目来实现。 如果已启用自动故障转移组并在应用程序连接字符串中使用读写和只读侦听器，则无需进一步操作，因为连接将自动定向到新的主服务器。
- 标识（并选择性定义）用户访问新的主数据库时所需的防火墙规则。
- 标识（并选择性创建）新主服务器的
master数据库中必须存在的登录名，并确保这些登录名在master数据库中具有相应权限（若有）。 有关详细信息，请参阅灾难恢复后的 Azure SQL 数据库安全性。 - 标识需要更新才能映射到新的主服务器的警报规则。
- 记录当前主服务器上的审核配置，并在辅助服务器上进行相同的配置。
- 查看 Azure SQL 数据库灾难恢复指南。
- 查看 Azure SQL 数据库的 SLA。
- 若要了解 Azure SQL 数据库的自动备份，请参阅 SQL 数据库自动备份。
- 若要了解业务连续性设计和恢复方案，请参阅连续性方案。
- 若要了解如何使用自动备份进行恢复，请参阅 从服务启动的备份中还原数据库。
- 详细了解活动异地复制。
- 详细了解故障转移组。
- 详细了解异地还原。
- 详细了解区域冗余数据库。