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