进一步了解可用性
默认情况下，Azure SQL 数据库和 Azure SQL 托管实例在各种服务层级中提供了很好的可用性选项。 可以执行一些其他操作来增加或修改数据库/实例的可用性。 可以直接看到对服务级别协议 (SLA) 所造成的影响。 在本单元中，你将进一步了解 Azure SQL 中的各种可用性选项。
可用性区域
在 Azure SQL 数据库的业务关键层级中，如果区域支持，可以选择加入（无需额外费用）区域冗余配置。 概括来讲，业务关键数据库和托管实例后运行的 Always On 可用性组 (AG) 部署在一个区域内的三个可用性区域中。 可用性区域实际上是指定区域内的独立数据中心。 与其他可用性区域之间始终存在物理分隔。 此功能可防止区域内的数据中心发生灾难性故障。
从性能角度来看，网络延迟可能会略有增加，因为 AG 现在跨数据中心分布，且各数据中心之间有一定距离。 因此，默认情况下不启用可用性区域。 可以选择使用通常称为“Multi-Az”或“Single-Az”的部署。 配置此选项非常简单，类似于向 PowerShell/Azure CLI 命令添加参数，或在 Azure 门户中选中某个框。
可用性区域在 Azure SQL 中相对较新，因此目前仅适用于特定区域和服务层级。 随着时间的推移，该功能可能会适用于更多区域和服务层级。 例如，Azure SQL 数据库的常规用途层最近发布了多 az 部署的预览版。
Azure SQL SLA
Azure SQL 维护服务级别协议 (SLA)，为实现和维护服务级别的承诺提供财务支持。 如果未按 SLA 中所述实现和维持服务级别，则你可能会获得月度服务费的一部分的额度。
目前，可以通过配置了可用性区域的 Azure SQL 数据库业务关键部署来实现最高可用性 (99.995%)。 业务关键层级是行业中唯一能够分别提供 5 到 30 秒的 RPO 和 RTO SLA 的选项。
- RPO 是恢复点目标 (recovery point object) 的缩写。 表示在最糟糕的情况下愿意丢失的数据量。
- RTO 是恢复时间目标 (recovery time objective) 的缩写。 表示在发生灾难时备份并重新运行所需的时间。
对于 Azure SQL 数据库或 Azure SQL 托管实例的常规用途或单区域业务关键部署，SLA 为99.99%。
超大规模层级的 SLA 取决于副本数。 请记住在超大规模层级中所选的副本数。 如果没有副本，则进行故障转移时，情况更类似于常规用途的故障转移。 如果有副本，则该故障转移行为更类似于业务关键的故障转移行为。 下面是基于副本数的 SLA：
- 0 个副本：99.5%
- 1 个副本：99.9%
- 2 个或多个副本：99.99%
异地复制和自动故障转移组
选择服务层级（并在适用时考虑可用性区域）后，还可以考虑使用其他一些选项获取读取缩放或故障转移到其他区域的能力：异地复制和自动故障转移组。 在本地 SQL Server 中，配置任一选项均需要进行大量规划、协调和时间。
云和 Azure SQL 专门简化了此过程。 对于异地复制和自动故障转移组，只需在 Azure 门户中单击几下鼠标或在 PowerShell/Azure CLI 中执行几条命令即可配置完毕。
以下一些注意事项可以帮助确定异地复制或自动故障转移组是否最适合你的方案：
| 功能 | 异地复制 | 故障转移组 |
|---|---|---|
| 自动故障转移 | 否 | 是 |
| 同时故障转移多个数据库 | 否 | 是 |
| 用户必须在故障转移后更新连接字符串 | 是 | 否 |
| SQL 托管实例支持 | 否 | 是 |
| 可以与主服务器位于同一区域 | 是 | 否 |
| 多个副本 | 是 | 否 |
| 支持读取缩放 | 是 | 是 |