通过冗余的可用性 - Azure SQL 数据库
适用于：
Azure SQL 数据库
本文介绍 Azure SQL 数据库的体系结构，在该体系结构下可通过本地冗余实现可用性，并通过区域冗余实现的高可用性。
概述
SQL 数据库在 Windows 操作系统上稳定的最新版 SQL Server 数据库引擎上运行，其中包含所有适用的修补程序。 SQL 数据库会自动处理关键的维护任务（例如修补、备份、Windows 和 SQL 引擎升级），以及底层硬件故障、软件故障或网络故障等计划外事件。 修补或故障转移 SQL 数据库中的数据库或弹性池时，如果在应用中使用重试逻辑，则停机不会产生影响。 即使出现最严重的问题，SQL 数据库也能快速恢复，确保数据始终可用。 大多数用户不会注意到升级是持续执行的。
默认情况下，Azure SQL 数据库通过本地冗余实现可用性，使数据库在以下过程中可用：
- 导致短暂停机的客户启动的管理操作
- 服务维护操作
- 与以下对象相关的问题：
- 为服务提供支持的计算机运行所在的机架
- 托管 SQL 数据库引擎的物理计算机
- SQL 数据库引擎的其他问题
- 其他潜在的计划外本地中断
默认可用性解决方案旨在确保提交的数据永远不会由于故障而丢失，维护操作不会影响工作负载，且数据库不会成为软件体系结构中的单一故障点。
但是，若要在发生整个区域中断时尽量减少对数据的影响，可以通过启用区域冗余来实现高可用性。 如果没有区域冗余，故障转移会在同一数据中心的本地发生，这可能会导致数据库在中断得到解决之前不可用；唯一的恢复方法是通过灾难恢复解决方案进行恢复，例如通过异地冗余备份的活动异地复制、故障转移组或异地还原进行异地故障转移。 要了解详细信息，请查看业务连续性概述。
有三种可用性体系结构模型：
- 基于计算和存储隔离的远程存储模型。 该模型依赖于远程存储层的可用性和可靠性。 此体系结构面向可以容忍在维护活动期间出现一定程度的性能下降的预算导向型业务应用程序。
- 基于数据库引擎进程群集的本地存储模型。 该模型依赖于以下事实：始终存在可用数据库引擎节点的仲裁。 此体系结构面向具有较高 IO 性能和较高事务处理率的任务关键型应用程序，保证维护活动期间尽量减小对工作负载性能造成的影响。
- 超大规模模型，它使用包含高度可用组件的分布式系统，例如计算节点、页面服务器、日志服务和持久存储。 支持超大规模数据库的每个组件都提供自身的冗余和故障复原能力。 计算节点、页面服务器和日志服务都运行在 Azure Service Fabric 上，后者控制每个组件的运行状况，并在必要时将数据故障转移到可用的正常节点。 持久存储使用 Azure 存储的本机高可用性和冗余功能。 若要了解详情，请参阅超大规模体系结构。
在三种可用性模型中，SQL 数据库都支持本地冗余和区域冗余选项。 本地冗余提供数据中心内的弹性，而区域冗余则通过防止区域内可用性区域出现中断来进一步提高复原能力。
下表显示了基于服务层的可用性选项：
| 服务层级 | 高可用性模型 | 本地冗余可用性 | 区域冗余可用性 |
|---|---|---|---|
| 常规用途 (vCore) | 远程存储 | 是 | 是 |
| 业务关键 (vCore) | 本地存储 | 是 | 是 |
| 超大规模 (vCore) | 超大规模 | 是 | 是 |
| 基本 (DTU) | 远程存储 | 是 | 否 |
| 标准 (DTU) | 远程存储 | 是 | 否 |
| 高级 (DTU) | 本地存储 | 是 | 是 |
有关不同服务层的特定 SLA 的详细信息，请查看适用于 Azure SQL 数据库的 SLA。
通过本地冗余实现可用性
本地冗余可用性基于将数据库存储到本地冗余存储 (LRS) 中，该存储在主要区域的单个数据中心内复制数据三次，并在发生本地故障（例如小规模网络或电源故障）时保护数据。 与其他选项相比，LRS 是成本最低的冗余选项，但提供的持久性也最低。 如果区域内发生火灾或洪水等大规模灾难，使用 LRS 的存储帐户的所有副本可能会丢失或无法恢复。 因此，为了在使用本地冗余可用性选项时进一步保护数据，请考虑为数据库备份使用更具弹性的存储选项。 这不适用于超大规模数据库，因为在该数据库中，数据文件和备份使用的是相同的存储。
所有服务层级和恢复点目标 (RPO) 中的所有数据库都可以使用本地冗余可用性，这表示数据丢失量为零。
基本、标准和常规用途服务层级
基于 DTU 的购买模型的基本、标准和常规用途服务层级以及基于 vCore 的购买模型的常规用途服务层级使用远程存储可用性模型来实现无服务器和预配计算。 下图显示了具有隔离的计算和存储层的四个不同节点。
远程存储可用性模型包括两个层：
- 无状态计算层：运行数据库引擎进程，仅包含暂时性的缓存数据，例如在附加的 SSD 上的
tempdb和model数据库，内存中的计划缓存、缓冲池和列存储池。 此无状态节点由 Azure Service Fabric 运行。后者会初始化数据库引擎、控制节点运行状况，并根据需要执行到另一节点的故障转移。 - 有状态数据层，包含存储在 Azure Blob 存储中的数据库文件（
.mdf和.ldf）。 Azure Blob 存储具有内置的数据可用性和冗余功能。 它可以保证即使数据库引擎进程崩溃，日志文件中的每条记录或者数据文件中的页面也仍会得到保留。
每当升级数据库引擎或操作系统，或者检测到故障时，Azure Service Fabric 会将无状态数据库引擎进程移到具有足够可用容量的另一个无状态计算节点。 Azure Blob 存储中的数据不受移动操作的影响，数据/日志文件将附加到新初始化的数据库引擎进程。 此过程保证高可用性，但在过渡期间，繁重工作负载的性能可能会有一定程度的下降，因为新的数据库引擎进程是使用冷缓存启动的。
“高级”和“业务关键”服务层级
基于 DTU 的购买模型的高级服务层级以及基于 vCore 的购买模型的业务关键服务层级使用本地存储可用性模型，该模型与单个节点上的计算资源（数据库引擎进程）和存储（本地附加的 SSD）相集成。 实现高可用性的方式是将计算和存储资源复制到其他节点。
底层数据库文件 (.mdf/.ldf) 放在附加的 SSD 存储中，以便为工作负荷提供延迟极低的 IO。 高可用性是使用类似于 SQL Server Always On 可用性组的技术来实现的。 群集包含可供读/写客户工作负载访问的单个主要副本，最多包含三个次要副本（计算和存储），这些副本包含数据的副本。 主要副本不断地将更改按顺序推送到次要副本，在提交每个事务之前，它可确保数据保留到足够数量的次要副本上。 此过程可以保证，当主要副本或可读次要副本因任何原因崩溃时，始终可以故障转移到某个完全同步的副本。 故障转移由 Azure Service Fabric 启动。 次要副本成为新的主要副本后，将创建另一个次要副本，以确保群集具有足够数量的副本来维护仲裁。 故障转移完成后，Azure SQL 连接会自动重定向到新的主要副本或可读次要副本。
作为一项额外的优势，本地存储可用性模型提供用于将只读 Azure SQL 连接重定向到某个次要副本的功能。 此功能称为读取扩展。它通过主要副本免费提供 100% 的额外计算容量，以减轻分析工作负荷等只读操作的负担。
“超大规模”服务层级
“超大规模”服务层级体系结构在分布式函数体系结构中进行了介绍。
“超大规模”中的可用性模型包括四个层：
- 无状态计算层：运行数据库引擎进程，仅包含暂时性缓存数据，例如在附加的 SSD 上的非覆盖性 RBPEX 缓存、
tempdb和model数据库等，以及内存中的计划缓存、缓冲池和列存储池。 此无状态层包括主要计算副本，并且可以包括许多能够用作故障转移目标的次要计算副本。 - 由页服务器组成的无状态存储层。 此层是在计算副本上运行的数据库引擎进程的分布式存储引擎。 每个页面服务器仅包含暂时性的缓存数据，例如附加的 SSD 上的覆盖性 RBPEX 缓存、在内存中缓存的数据页。 每个页服务器在主动-主动配置中都有一个配对的页服务器，用于提供负载均衡、冗余性和高可用性。
- 一个有状态事务日志存储层，包含运行日志服务进程的计算节点、事务日志登陆区域，以及事务日志长期存储。 登陆区域和长期存储使用 Azure 存储，后者提供事务日志所需的可用性和冗余性，确保已提交事务的数据持久性。
- 有状态数据存储层，包含的数据库文件 (.mdf/.ndf) 存储在 Azure 存储中并通过页服务器进行更新。 此层使用 Azure 存储的数据可用性和冗余功能。 它保证保存数据文件中的每个页面，即使“超大规模”体系结构的其他层中的进程崩溃或计算节点故障，也是如此。
所有“超大规模”层中的计算节点都运行在 Azure Service Fabric 上，后者控制每个节点的运行状况，并在必要时将数据故障转移到可用的健康节点。
若要详细了解超大规模中的高可用性，请参阅超大规模中的数据库高可用性。
通过区域冗余实现高可用性
区域冗余可用性可确保数据分布在主要区域的三个 Azure 可用性区域中。 每个可用性区域都是一个独立的物理位置，具有独立的电源、冷却系统和网络。
区域冗余可用性适用于基于 vCore 的购买模型的业务关键、常规用途和超大规模服务层级中的数据库，仅适用于基于 DTU 的购买模型的高级服务层级中的数据库 - 基本和标准服务层级不支持区域冗余。
虽然每个服务层级实现区域冗余的方式不尽相同，但所有实现都能确保恢复点目标 (RPO) 在故障转移时不会丢失提交的数据。
“常规用途”服务层级
同时为适用于 vCore 购买模型中数据库的无服务器和预配计算提供了常规用途服务层的区域冗余配置。 此配置会利用 Azure 可用性区域跨 Azure 区域中的多个物理位置复制数据库。 通过选择区域冗余，你可以使新的和现有的无服务器和预配常规用途单一数据库和弹性池能够灵活应对范围要广得多的故障（包括灾难性的数据中心服务中断），且不会对应用程序逻辑进行任何更改。
“常规用途”层级的区域冗余配置有两个层：
- 有状态数据层：包含存储在 ZRS（区域冗余存储）中的数据库文件 (.mdf/.ldf)。 使用 ZRS 时，数据和日志文件会同步复制到三个进行了物理隔离的 Azure 可用性区域中。
- 无状态计算层：运行 sqlservr.exe 进程，仅包含暂时性的缓存数据，例如在附加的 SSD 上的
tempdb和model数据库，内存中的计划缓存、缓冲池和列存储池。 此无状态节点由 Azure Service Fabric 运行。后者会初始化 sqlservr.exe、控制节点运行状况，并根据需要执行到另一节点的故障转移。 对于区域冗余无服务器和预配常规用途数据库，具有备用容量的节点可在其他可用性区域中轻松地用于故障转移。
下图演示了适用于“常规用途”服务层级的高可用性体系结构的区域冗余版本：
使用区域冗余配置常规用途数据库时，请考虑以下事项：
- 对于“常规用途”层，区域冗余配置在以下区域中正式发布：
- (亚太)中国北部 3
- 仅当选择标准系列 (Gen5) 硬件后，区域冗余配置才在 SQL 数据库中可用。
- 区域冗余不适用于 DTU 购买模型中的基本和标准服务层级。
“高级”和“业务关键”服务层级
为高级或业务关键服务层启用区域冗余时，副本放置在同一区域的不同可用性区域中。 若要消除单一故障点，还要将控件环跨区域地复制为三个网关环 (GW)。 到特定网关环的路由受 Azure 流量管理器的控制。 由于高级或业务关键服务层级中的区域冗余配置使用其现有副本来放置在不同的可用性区域中，因此无需额外付费即可启用它。 通过选择区域冗余配置，可以使“高级”或“业务关键”数据库和弹性池能够应对范围要广得多的故障（包括灾难性的数据中心服务中断），且不会对应用程序逻辑进行任何更改。 还可以将所有现有“高级”或“业务关键”数据库或弹性池转换到区域冗余配置。
下图演示了高可用性体系结构的区域冗余版本：
使用区域冗余配置高级或业务关键数据库时，请考虑以下事项：
- 有关支持区域冗余数据库的区域的最新信息，请参阅按区域提供的服务支持。
- 对于区域冗余可用性，选择维护时段，而不是目前在选择区域中提供的默认设置。
“超大规模”服务层级
可以在“超大规模”服务层级中为数据库配置区域冗余。 若要了解详细信息，请参阅创建区域冗余超大规模数据库。
启用此配置后，通过所有“超大规模”层级的可用性区域间的复制，确保区域级别的复原能力。 通过选择区域冗余，可以使“超大规模”数据库能够灵活应对范围要广得多的故障（包括灾难性的数据中心服务中断），且不会对应用程序逻辑进行任何更改。 具有可用性区域的所有 Azure 区域都支持区域冗余超大规模数据库。
下图演示了区域冗余超大规模数据库的基础体系结构：
请考虑以下限制：
区域冗余配置只能在数据库创建期间指定。 预配资源后将无法修改此设置。 使用数据库复制、时间点还原，或创建异地副本来更新现有“超大规模”数据库的区域冗余配置。 使用这些更新选项之一时，如果目标数据库与源数据库位于不同的区域，或者目标数据库的数据库备份存储冗余与源数据库不同，则复制操作将是数据操作的大小。
在使用 Azure 门户将数据库迁移到“超大规模”时，目前没有用于指定区域冗余的选项。 不过，在将现有数据库从其他 Azure SQL 数据库服务层级迁移到“超大规模”时，可使用 Azure PowerShell、Azure CLI 或 REST API 来指定区域冗余。 下面是 Azure CLI 的示例：
az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true`要为“超大规模”启用区域冗余配置，至少需要 1 个高可用性计算副本并使用区域冗余或异地区域冗余备份存储。
数据库区域冗余可用性
在 Azure SQL 数据库中，服务器是一个逻辑构造，充当数据库集合的中心管理点。 在服务器级别，可以管理登录名、身份验证方法、防火墙规则、审核规则、威胁检测策略和故障转移组。 与其中某些功能（如登录和防火墙规则）相关的数据存储在 master 数据库中。 同样，某些 DMV（例如 sys.resource_stats）的数据也存储在 master 数据库中。
在逻辑服务器上创建具有区域冗余配置的数据库时，与服务器关联的 master 数据库也会自动成为区域冗余。 这样可确保出现区域故障时，使用数据库的应用程序不受影响，因为依赖于 master 数据库的功能（如登录和防火墙规则）仍然可用。 使 master 数据库成为区域冗余是一个异步过程，需要一些时间才能在后台完成。
如果服务器上的所有数据库均不是区域冗余，或者创建了空服务器，那么与该服务器关联的 master 数据库并非区域冗余。
可以使用 Azure PowerShell、Azure CLI 或 REST API 检查 master 数据库的 ZoneRedundant 属性：
使用以下示例命令检查 master 数据库的“ZoneRedundant”属性值。
Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"
测试应用程序的故障复原能力
高可用性是 SQL 数据库平台的基本功能，其运作对数据库应用程序透明。 不过，我们认识到，你可能需要先测试在计划内或计划外事件期间启动的自动故障转移操作对应用程序的具体影响，然后才会将其部署到生产环境。 可以通过调用特殊 API 重启数据库或弹性池来手动触发故障转移。 在使用区域冗余无服务器或预配常规用途数据库或弹性池的情况下，API 调用会导致将客户端连接重定向到与旧主节点的可用性区域不同的可用性区域中的新主节点。 因此，除了测试故障转移对现有数据库会话的影响外，还可以验证它是否会由于网络延迟的变化而改变了端到端性能。 由于重启操作会干扰系统，其数量过多可能会对平台造成压力，因此每个数据库或弹性池每 15 分钟只能进行一次故障转移调用。
有关 Azure SQL 数据库高可用性和灾难恢复的详细信息，请参阅高可用性和灾难恢复清单。
可以使用 PowerShell、REST API 或 Azure CLI 启动故障转移：
| 部署类型 | PowerShell | REST API | Azure CLI |
|---|---|---|---|
| 数据库 | Invoke-AzSqlDatabaseFailover | 数据库故障转移 | az rest 可用于从 Azure CLI 调用 REST API 调用 |
| 弹性池 | Invoke-AzSqlElasticPoolFailover | 弹性池故障转移 | az rest 可用于从 Azure CLI 调用 REST API 调用 |
重要
故障转移命令不可用于超大规模数据库的可读次要副本。
结论
Azure SQL 数据库提供与 Azure 平台深度集成的内置高可用性解决方案。 它依赖于使用 Service Fabric 来执行故障检测和恢复，依赖于 Azure Blob 存储来实现数据保护，并依赖于可用性区域来提高容错能力。 此外，SQL 数据库利用 SQL Server 的 Always On 可用性组技术来执行数据同步和故障转移。 将这些技术相结合，应用程序可完全实现混合存储模型的优势并支持最严格的 SLA。
相关内容
若要了解详细信息，请查看：