Azure SQL Database提供企业级可用性SLA来支持各种应用程序，包括任务关键型应用程序，始终需要可用。 Azure SQL Database还具有关键业务连续性功能，可以在发生区域性中断时快速进行灾难恢复。 本文包含在部署应用程序之前需查看的重要信息。
尽管我们不断努力提供可用性，但有时Azure SQL Database服务发生中断，导致数据库不可用，从而影响应用程序。 当我们的服务监视检测到导致广泛连接错误、故障或性能问题的问题时，服务会自动声明中断，以随时通知你。
服务中断
如果发生Azure SQL Database服务中断，可以在以下位置找到与中断相关的更多详细信息：
Azure 门户横幅
如果您的订阅被识别为受影响，在Azure门户通知中，将显示服务问题的故障警报：
帮助与支持或支持和故障排除
从帮助与支持或支持和故障排除创建支持票证时，将提供有关影响资源的任何问题的信息。 选择查看中断详细信息，以获取详细信息和影响摘要。 新建支持请求页中还会显示一个警报。
服务运行状况
Azure 门户中的 Service Health 页包含全局Azure数据中心状态的相关信息。 在Azure门户中的搜索栏中搜索“服务运行状况”，然后在 Active events 类别中查看 Service issues。 还可以在帮助菜单下任何资源的资源运行状况页中查看单个资源的运行状况。
电子邮件通知
如果已设置警报，当服务中断影响订阅和资源时，你将收到来自
azure-noreply@microsoft.com的电子邮件通知。 电子邮件正文通常以“活动日志警报...因Azure订阅的服务故障而被触发...”开始。 有关服务运行状况警报的详细信息，请参阅使用 Azure 门户接收有关 Azure 服务通知的活动日志警报。
中断期间何时启动灾难恢复
如果服务中断影响应用程序资源，请考虑以下操作过程：
Azure团队努力尽快还原服务可用性，但根据根本原因，有时可能需要几个小时。 如果应用程序可以容忍长时间停机，则可以等待恢复完成。 在此情况下，不需要采取任何操作。 在帮助菜单下任何资源的资源运行状况页中查看单个资源的运行状况。 有关中断的更新和最新信息，请参阅“资源运行状况”页。 在区域恢复后，会还原应用程序的可用性。
恢复到另一个Azure区域可能需要更改应用程序连接字符串或使用 DNS 重定向，并可能导致永久数据丢失。 因此，仅当中断持续时间接近应用程序的恢复时间目标 (RTO) 时，才应执行灾难恢复。 将应用程序部署到生产环境时，应定期监视应用程序的运行状况，并断言仅当应用程序层与数据库之间出现长时间连接失败时，才保证恢复。 根据应用程序对故障时间和可能的业务责任的容忍度，你可以决定是等待服务恢复还是自行启动灾难恢复。
中断恢复指南
如果区域中的Azure SQL Database中断已长时间未缓解，并且影响应用程序的服务级别协议（SLA），请考虑以下步骤：
故障转移（无数据丢失）到异地复制副服务器
如果已启用活动地理复制或故障转移组，请在 Azure 门户中检查主数据库和辅助数据库资源状态是否为联机。 如果是，则主数据库和辅助数据库的数据平面都正常。 使用 Azure 门户、T-SQL、PowerShell 或Azure CLI启动活动异地复制或故障转移组到次要区域的故障转移。
注意
故障切换需要在切换角色之前完成全部数据同步，并且不会出现数据丢失。 根据服务中断的类型，无法保证成功实现故障转移（无数据丢失），但作为第一个恢复选项，值得一试。
要启动故障转移，请使用以下链接：
| 技术 | 方法 | 步骤 |
|---|---|---|
| 活动异地复制 | PowerShell | 通过 PowerShell 故障转移到地理复制的备用节点 |
| T-SQL | 通过 T-SQL 故障转移到地理复制的辅助服务器 | |
| 故障转移组 | Azure CLI | 通过 Azure CLI 切换到辅助服务器 |
| Azure 门户 | 通过 Azure 门户将Failover 连接到辅助服务器 | |
| PowerShell | 通过 PowerShell 切换到备用服务器 |
强制故障转移（可能丢失数据）到异地复制辅助服务器
如果故障转移未正常完成并遇到错误，或者主数据库不处于联机状态，请仔细考虑强制故障转移（可能丢失数据）到次要区域。
强制启动故障转移，请使用以下链接：
| 技术 | 方法 | 步骤 |
|---|---|---|
| 活动异地复制 | Azure CLI | 通过 Azure CLI 强制故障转移至异地复制的次要副本 |
| Azure 门户 | 通过 Azure 门户故障转移到异地复制辅助副本 | |
| PowerShell | 通过 PowerShell 强制故障转移到异地复制辅助服务器 | |
| T-SQL | 通过 T-SQL 强制故障转移到异地复制辅助服务器 | |
| 故障转移组 | Azure 门户 | 通过 Azure 门户强制故障转移到辅助服务器，然后选择强制故障转移。 |
| Azure CLI |
通过 Azure CLI 强制故障转移到辅助服务器 但使用 --allow-data-loss |
|
| PowerShell |
通过 PowerShell 强制故障转移到辅助服务器但使用 -AllowDataLoss |
地理还原
如果尚未启用主动异地复制或故障转移群组，作为最后的手段，您可以使用地理还原从中断中恢复。 异地还原使用异地复制的备份作为源。 您可以从最近的地理复制备份中，在任何 Azure 区域的任何逻辑服务器上还原数据库。 即使服务中断导致数据库或整个区域无法访问，也依然能够请求异地还原。
有关通过 Azure CLI、Azure 门户、PowerShell 或 REST API 进行异地还原的详细信息，请参阅 geo-restore of Azure SQL Database。
恢复后配置数据库
在服务中断后，如果使用异地故障转移或异地还原进行恢复，则必须确保已正确配置与新数据库的连接，以便恢复正常的应用程序功能。 以下任务清单用于让恢复的数据库做好生产准备。
重要
建议定期演练灾难恢复策略，以验证应用程序容忍度，以及恢复过程的所有操作方面。 应用程序基础结构的其他层可能需要重新配置。 有关可复原体系结构步骤的详细信息，请查看 Azure SQL Database高可用性和灾难恢复清单。
更新连接字符串
- 如果使用活动异地复制或异地还原，则必须确保已正确配置与新数据库的连接，以便恢复正常的应用程序功能。 由于恢复的数据库位于不同的服务器中，因此需要更新应用程序的connection string以指向该服务器。 若要深入了解如何更改连接字符串，请参阅连接库的相应开发语言。
- 在服务中断后，如果使用故障转移组进行恢复，并在应用程序连接字符串中使用读写和只读侦听器，则无需进一步操作，因为连接将自动定向到新的主服务器。
配置防火墙规则
需确保辅助服务器和数据库上配置的防火墙规则与主服务器和主数据库上配置的防火墙规则匹配。 有关详细信息，请参阅如何：配置防火墙设置。
配置登录名和数据库用户
创建新主服务器的 master 数据库中必须存在的登录名，并确保这些登录名在 master 数据库中具有相应权限（若有）。 相关详细信息，请参阅灾难恢复后的安全性。
设置遥测警报
需确保更新现有的警报规则设置，以便映射到新的主数据库和不同的服务器。 有关数据库警报规则的详细信息，请参阅接收警报通知和跟踪服务运行状况。
启用审核
如果在主服务器上配置了审核，则使它与辅助服务器上的审核相同。 有关详细信息，请参阅审核。
相关内容
若要了解详细信息，请查看：
- 连续性方案。
- 自动备份
- 从服务启动的备份还原数据库。
- 若要了解更快的恢复选项，请参阅活动异地复制和故障转移组。
- 查看灾难恢复指南和高可用性和灾难恢复清单。