使用 Azure SQL 数据库确保业务连续性的相关概述
适用于：
Azure SQL 数据库
本文概述了Azure SQL 数据库的业务连续性和灾难恢复功能，介绍了从中断事件中恢复的选项和建议，这些事件可能导致数据丢失或导致数据库和应用程序不可用。 了解对一些情况的处理方式，包括用户或应用程序错误影响数据完整性、Azure 可用性区域或区域发生服务中断，或者应用程序需要维护。
概述
Azure SQL 数据库中的业务连续性是指通过提供可用性、高可用性和灾难恢复，使企业能够继续在中断时继续运营的机制、策略和过程。
大多数情况下，SQL 数据库会处理云环境中可能发生的中断事件，让应用程序和业务流程保持运行状态。 然而，在一些破坏性事件中，缓解措施可能需要一些时间，例如：
- 用户意外删除或更新了表中的某行。
- 恶意攻击者成功删除了数据或数据库。
- 灾难性自然灾害事件导致数据中心或可用性区域或区域瘫痪。
- 罕见的由配置更改、软件错误或硬件组件故障引起的数据中心、可用性区域或区域性中断。
可用性
Azure SQL 数据库具有核心复原和可靠性承诺，可防范软件或硬件故障。 自动化数据库备份，以保护数据免受损坏或意外删除。 作为平台即服务（PaaS），Azure SQL 数据库服务以现成的功能提供可用性，行业领先的可用性 SLA 为 99.99%。
高可用性
若要在 Azure 云环境中实现高可用性，请启用 区域冗余 ，以便数据库或弹性池使用 可用性区域 来确保数据库或弹性池能够复原到区域性故障。 许多 Azure 区域可提供可用性区域，这些区域是一个区域内的独立数据中心组，具有独立的电源、冷却和网络基础结构。 可用性区域旨在当一个区域出现中断时，在其余区域提供区域服务、容量和高可用性。 通过启用区域冗余，数据库或弹性池可复原到区域性硬件和软件故障，恢复对应用程序是透明的。 启用高可用性后，Azure SQL 数据库服务可提供 99.995% 的高可用性 SLA。
灾难恢复
若要跨区域实现更高的可用性和冗余，可以启用灾难恢复功能，以便从灾难性区域故障中快速恢复数据库。 Azure SQL 数据库灾难恢复选项：
- 通过活动异地复制功能，可以为主数据库创建在任何区域的持续同步的可读辅助数据库。
- 除了在主数据库和辅助数据库之间提供连续同步之外，故障转移组还允许管理逻辑服务器上某些或所有数据库的副本 (replica)和故障转移，以及将逻辑服务器上的一些或所有数据库故障转移到另一个区域中的辅助逻辑服务器。 故障转移组可提供保持不变的读写和只读侦听器端点，因此无需在故障转移后更新应用程序连接字符串。
- 异地还原允许通过在任何 Azure 区域中的任何现有服务器上创建新数据库来从异地副本备份还原，从而从异地副本备份恢复区域中断。
下表比较了活动异地副本和故障转移组，两个灾难恢复选项用于Azure SQL 数据库：
| 活动异地复制 | 故障转移组 | |
|---|---|---|
| 主数据库和辅助数据库之间的连续数据同步 | 是 | 是 |
| 同时故障转移多个数据库 | 否 | 是 |
| 故障转移后连接字符串保持不变 | 否 | 是 |
| 支持读取缩放 | 是 | 是 |
| 多个副本 | 是 | 否 |
| 可以与主服务器位于同一区域 | 是 | 否 |
可提供业务连续性的功能
从数据库角度看，主要有四种潜在的中断场景。 下表列出了可用于缓解潜在业务中断方案的SQL 数据库业务连续性功能：
| 业务中断应用场景 | 业务连续性功能 |
|---|---|
| 影响数据库节点的本地硬件或软件故障。 | 为了缓解本地硬件和软件故障问题，SQL 数据库包含一个可用性体系结构，可以保证在出现这些故障时自动进行恢复，其可用性 SLA 高达99.99%。 |
| 通常由应用程序 bug 或人为失误导致的数据损坏或删除。 此类故障特定于应用程序，通常无法通过数据库服务检测到。 | 为了防止企业丢失数据，SQL 数据库每周自动创建完整数据库备份，每 12 小时或 24 小时自动创建差异数据库备份，每隔 5 - 10 分钟自动创建事务日志备份。 默认情况下，所有服务层级的备份都会在异地冗余存储中存储 7 天。 对于时间点还原，所有服务层级（“基本”层级除外）都支持可配置的备份保留期，最长为 35 天。 如果服务器尚未删除或者已配置长期保留 (LTR)，可将已删除的数据库还原到删除时的时间点。 |
| 罕见的由自然灾害事件、配置更改、软件错误或硬件组件故障引起的数据中心或可用性区域中断。 | 若要缓解数据中心或可用性区域级别的中断，请为数据库或弹性池启用区域冗余，以使用 Azure 可用性区域，并在 Azure 区域中的多个物理区域中提供冗余。 启用区域冗余可确保数据库或弹性池能够复原到具有高达 99.995% 高可用性 SLA 的区域性故障。 |
| 罕见的区域中断 会影响所有可用性区域及其构成的数据中心，可能是由灾难性自然灾害事件引起的。 | 若要缓解区域范围的中断，请使用以下选项之一启用灾难恢复： - 连续数据同步选项（例如故障转移组（建议）或活动异地副本 (replica)，使你可以在次要区域中创建副本 (replica)进行故障转移。 将备份存储冗余选项配置为异地冗余备份存储，以使用异地还原功能。 |
RTO 和 RPO
制定业务连续性计划时，请了解应用程序在中断事件发生后完全恢复之前的最大可接受时间。 应用程序完全恢复所需的时间称为“恢复时间目标”(RTO)。 还要了解从计划外中断事件恢复时，应用程序可忍受最近数据更新丢失的最长期限（时间间隔）。 可能的数据丢失称为恢复点目标 (RPO)。
下表比较了每个业务连续性选项的 RPO 和 RTO：
| 业务连续性选项 | RTO（故障时间） | RPO（无数据丢失） |
|---|---|---|
| 高可用性 （使用区域冗余） |
通常不到30秒 | 0 |
| 灾难恢复 （将故障转移组与客户管理的故障转移策略或活动异地复制配合使用） |
通常不到60秒 | 等于或大于 0 （取决于数据更改之前尚未副本的中断事件） |
使用异地还原进行灾难恢复 |
通常为分钟或小时 | 通常为分钟或小时 |
业务连续性检查列表
有关最大化可用性并实现更高业务连续性的规范性建议，请参阅：
为进行地区移动做准备
无论使用哪种业务连续性功能，都必须在另一个区域中准备辅助数据库。 如果准备不适当，故障转移或恢复数据库后，需要花更多时间让应用程序联机，还有可能要在这种情况下需要进行故障排除，从而会延长停机时间。 按照检查列表准备次要区域中断。
恢复同一 Azure 区域内的数据库
可以使用自动数据库备份将数据库还原到过去的某个时间点。 可以通过这种方式从人为错误导致的数据损坏中恢复。 可以通过时间点还原在同一服务器中创建一个新数据库，以表示损坏事件发生之前的数据状态。 大多数数据库的还原操作需要不到 12 小时的时间。 恢复非常大或十分活跃的数据库需要更长时间。 有关详细信息，请参阅数据库恢复。
如果支持的最长时间点还原 (PITR) 备份保留期对你的应用程序而言不足，则可以通过为数据库配置长期保留 (LTR) 策略来延长保留期。 有关详细信息，请参阅长期备份保留。
在停机时间最短的情况下升级应用程序
有时，应用程序由于计划内维护，例如应用程序升级，必须脱机。 管理应用程序升级介绍如何使用活动异地复制滚动升级云应用程序，将升级时的停机时间缩到最短，并在发生错误时提供恢复路径。
后续步骤
如果要考虑应用设计，请参阅设计用于云灾难恢复的应用程序和弹性池灾难恢复策略。