“超大规模”次要副本

项目
08/12/2024

适用于：Azure SQL 数据库

如分布式函数体系结构中所述，Azure SQL 数据库超大规模提供两种不同类型的计算节点（也称为副本）：

主要副本：为读取和写入操作提供服务
次要副本：提供读取扩展、高可用性和异地复制

次要副本始终为只读，可以是三种不同类型的副本：

高可用性副本
异地副本
命名副本

每种类型具有不同的体系结构、功能集、用途和成本。根据你需要的功能，可以只使用其中一种类型，也可以将所有三种类型一起使用。次要副本受无服务器和预配计算层级的支持。

有关配置和管理超大规模命名副本的教程，请参阅：

高可用性副本

高可用性 (HA) 副本使用与主要副本相同的页面服务器，因此无需进行数据复制即可添加 HA 副本。 HA 副本主要用于提高数据库可用性；它们在供故障转移时充当热备用服务器副本。如果主要副本不可用，系统会快速自动将故障转移到现有的其中一个 HA 副本。无需更改连接字符串；在故障转移期间，应用程序可能会因活动连接断开而出现极短暂的故障时间。像平常一样，建议对这种情况实施适当的连接重试逻辑。有多个驱动程序已经提供了一定程度的自动重试逻辑。如果使用 .NET，则最新的最新的 Microsoft.Data.SqlClient 库会为可配置的自动重试逻辑提供原生完全支持。

HA 副本使用的服务器和数据库名称与主要副本相同。其服务级别目标也始终与主要副本相同。 HA 副本作为独立资源无法从门户或任何 API 看到或管理。

可以创建 0 到 4 个 HA 副本。在创建数据库期间或之后，可以通过一般的管理终结点和工具（例如 PowerShell、AZ CLI、门户或 REST API）更改 HA 副本数量。创建或删除 HA 副本不会影响主要副本上运行的活动连接。

连接到 HA 副本

在超大规模数据库中，客户端使用的连接字符串中的 ApplicationIntent 参数决定连接是路由到可读写的主要副本，还是路由到只读的 HA 副本。如果将 ApplicationIntent 设置为 ReadOnly，并且数据库没有辅助副本，连接将路由到主要副本，并默认执行 ReadWrite 行为。

-- Connection string with application intent
Server=tcp:<myserver>.database.chinacloudapi.cn;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

所有 HA 副本的资源容量都相同。如果存在多个 HA 副本，则旨在读取的工作负载会任意分布在所有可用的 HA 副本中。如果存在多个 HA 副本，请记住，每个 HA 副本在处理主要副本上发生的数据更改方面可能会出现不同的数据延迟。每个 HA 副本使用与同一组页面服务器上的主要副本相同的数据。但是，每个 HA 副本上的本地缓存通过事务日志服务来反映主要副本上发生的更改，该服务会将主要副本中的日志记录转发到 HA 副本。因此，根据 HA 副本所处理的工作负载，应用程序日志记录的速度可能各不相同，因而不同的 HA 副本相对于主要副本而言可能会出现不同的数据延迟。

命名副本

与 HA 副本一样，命名副本使用与主要副本相同的页面服务器。类似于 HA 副本，无需进行数据复制即可添加命名副本。

HA 副本和命名副本之间存在差异：

命名副本在门户和 API（AZ CLI、PowerShell、T-SQL）调用中显示为普通（只读）Azure SQL 数据库。
命名副本的数据库名称可以不同于主要副本，并且可以选择性地放置在不同的逻辑服务器上（前提是位于主要副本所在的同一区域中）。
命名副本具有自身的服务级别目标，该目标可以独立于主要副本进行设置和更改。
命名副本最多支持 30 个命名副本（对于每个主要副本而言）。
命名副本支持通过在托管命名副本的逻辑服务器上创建不同的登录名，对每个命名副本使用不同的身份验证。

因此对于只读工作负载而言，命名副本与 HA 副本相比有诸多优势：

如果主要副本纵向扩展或纵向缩减，连接到命名副本的用户不会断开连接；同时连接到主要副本的用户将不受命名副本纵向扩展或缩减的影响。
在任何副本（主要副本或命名副本）上运行的工作负载不受在其他副本上运行的长期运行的查询影响。

命名副本的主要目标是支持多种的读取扩展场景，并改进混合事务和分析处理 (HTAP) 工作负载。下面提供了有关如何创建此类解决方案的示例：

OLTP 横向扩展示例

除了上面列出的主要方案以外，命名副本还提供其他许多用例所需的灵活性和弹性：

访问隔离：可以授予对特定命名副本的访问权限，但不能授予对主要副本或其他命名副本的访问权限。
工作负载相关的服务级别目标：由于命名副本可以有自身的服务级别目标，因此可为不同的工作负载和用例使用不同的命名副本。例如，可以使用一个命名副本来为 Power BI 请求提供服务，而使用另一个命名副本来为 Apache Spark for Data Science 任务提供数据。每个命名副本可以有独立的服务级别目标，并可独立缩放。
工作负载相关的路由：在命名副本数最多可达 30 个的情况下，可以按组使用命名副本，使应用程序可以相互隔离。例如，包含四个命名副本的组可用于为来自移动应用程序的请求提供服务，而包含两个命名副本的另一个组可用于为来自 Web 应用程序的请求提供服务。采用这种方法可以精细地调整每个组的性能和成本。

注意

有关超大规模命名副本的常见问题解答，请参阅 Azure SQL 数据库超大规模命名副本常见问题解答。

超大规模命名副本的区域冗余

Azure SQL 数据库超大规模命名副本的区域冗余使用 Azure 可用性区域在 Azure 区域内的不同物理位置之间分布命名副本计算节点。通过为命名副本选择区域冗余，可以增强超大规模数据库所有层对更广泛故障（包括数据中心中断）的复原能力，而无需对应用程序逻辑进行任何修改。有关详细信息，请参阅超大规模区域冗余可用性。

有关创建区域冗余超大规模命名副本的教程，请参阅创建超大规模命名副本。

有关故障排除和测试应用程序故障复原能力，请参阅测试应用程序故障复原能力。

异地副本

使用活动异地复制可以在相同或不同的 Azure 区域创建超大规模主要数据库的可读次要副本。必须在不同的逻辑服务器上创建异地副本。异地副本的数据库名称始终与主要副本的数据库名称相匹配。

创建异地副本时，会将主要副本中的所有数据复制到一组不同的页面服务器。异地副本不与主要副本共享页面服务器，即使它们位于同一区域。此体系结构为异地故障转移提供了必要的冗余。

异地副本用于通过异步复制维护数据库的事务一致副本。如果异地副本位于不同的 Azure 区域，当主要区域发生灾难或中断时，便可以使用异地副本进行灾难恢复。异地副本还可用于异地读取扩展方案。自 2022 年 10 月起，支持超大规模异地次要副本复制中的数据库副本。

超大规模数据库的异地复制目前有以下限制：

（在相同或不同的区域中）只能创建一个异地副本。
异地副本时间点还原不受支持。
不支持创建异地副本的异地副本（也称为“异地副本链”）。

疑难解答

排查区域冗余超大规模命名副本问题

有关故障排除和测试应用程序故障复原能力，请参阅测试应用程序故障复原能力。
确保在 PowerShell 和 CLI 中创建区域冗余命名副本时至少指定一个高可用性副本。有关示例，请参阅创建超大规模命名副本。
- 在 Azure CLI 中，必须同时指定参数 "ha-replicas" 和 "redundant"。
- 在 PowerShell 中，必须指定参数 "HighAvailabilityReplicaCount" 和 "ZoneRedundant"。
- 如果省略，你会收到错误消息：(ProvisioningDisabled) There is an insufficient number of high availability replicas to enable zone redundancy for a Hyperscale database.
超大规模数据库应已启用区域冗余，作为为命名副本启用此功能的先决条件。
- 即使主数据库已启用区域冗余，也可以选择为命名副本启用区域冗余。
- 如果未启用，你会收到错误消息：(DatabaseNamedReplicaSourceDatabaseNotZoneRedundant) Zone Redundancy cannot be enabled on this Named Replica since the primary Hyperscale Database is not zone redundant.。

已知问题

从 sys.databases 返回部分错误的数据

对于 name 和 database_id 以外的列中的命名副本，从 sys.databases 返回的行值可能不一致且不正确。例如，尽管从中创建了命名副本的主数据库设置为 150，但该命名副本的 compatibility_level 列有可能会报告为 140。如果可能，解决方法是使用 DATABASEPROPERTYEX() 函数获取相同的数据，该函数将返回正确的数据。