高可用性和灾难恢复

下载 ODBC 驱动程序

适用于 SQL Server 的 Microsoft ODBC 驱动程序支持 Always On 可用性组。 有关 AlwaysOn 可用性组的详细信息,请参阅:

你可以在连接字符串中指定特定可用性组的可用性组侦听程序。 如果 ODBC 应用连接到故障切换的可用性组数据库,则原始连接会中断。 该应用程序必须打开一个新连接才能在故障转移之后继续工作。

如果没有MultiSubnetFailover=Yes,当第一个解析出的 IP 地址无法访问时,驱动程序的旧版多 IP 回退机制速度可能会很慢。 有关 Windows 回退行为的详细信息,请参阅在 ODBC 驱动程序中使用透明网络 IP 解析。

当你通过使用 MultiSubnetFailover=Yes,连接到可用性组监听器时,驱动程序会尝试并行连接所有已解析的 IP 地址。 如果连接尝试成功,驱动程序将丢弃所有挂起的连接尝试。

注释

由于连接可能因可用性组故障转移而失败,因此请实现连接重试逻辑。 重试失败的连接,直到它重新连接。 增加连接超时时间和实现连接重试逻辑会提高连接到可用性组的几率。

使用 MultiSubnetFailover 进行连接

当目标对象是 Azure SQL 数据库、Azure SQL 托管实例、Microsoft Fabric 中的 SQL 数据库、可用性组监听器或故障转移集群实例时,设置MultiSubnetFailover=Yes。 MultiSubnetFailover 通过让驱动程序并行尝试与所有已解析出的 IP 地址建立 TCP 连接,并使用第一个成功建立的连接,实现更快的故障切换恢复。

此连接属性还可显著缩短单子网和多子网 Always On 拓扑的故障转移时间。 在多子网故障转移过程中,客户端将尝试并行连接。 在子网故障转移期间,驱动程序会主动重试 TCP 连接。

MultiSubnetFailover连接属性表明,该应用程序正在部署到一种拓扑中,其中目标主机名可能会解析为多个端点。 驱动程序会通过尝试连接到所有的 IP 地址,从而连接到主 SQL Server 实例上的数据库。

当你用 MultiSubnetFailover=Yes连接时,客户端会比操作系统默认的 TCP 重传间隔更快地重试 TCP 连接。 MultiSubnetFailover=Yes会在 AlwaysOn 可用性组或 Always On 故障转移群集实例的故障转移之后进行更快速的重新连接。 MultiSubnetFailover=Yes同时适用于单子网和多子网可用性组和故障转移群集实例。

MultiSubnetFailover=Yes 可安全用于单个 IP 目标。 当DNS解析到一个地址时, MultiSubnetFailover=Yes 不会创建额外的并行连接尝试。

Recommendations

连接到高可用或多端点目标(Azure SQL 数据库、Azure SQL 托管实例、Microsoft Fabric 中的 SQL 数据库、可用性组侦听器或故障转移群集实例)时:

  • 指定 MultiSubnetFailover=Yes。 这是针对这些目标的推荐设置;当目标解析为单个 IP 地址时,将其保持为开启状态也是安全的,因为驱动程序只会进行一次连接尝试。

  • 在连接字符串中将可用性组的可用性组侦听程序指定为服务器。

  • 你不能通过TCP以外的协议使用 MultiSubnetFailover=Yes 。

  • 不能连接到配置了超过 64 个 IP 地址的 SQL Server 实例。

  • 你不能将 MultiSubnetFailover=Yes 与数据库镜像一起使用。 当连接字符串指定Failover_Partner时,驱动程序会返回错误,同时服务器报告数据库已镜像。 所有支持的 SQL Server 版本均已弃用数据库镜像。 请使用 Always On 可用性组来替代其他解决方案。

  • SQL Server 身份验证或 Kerberos 身份验证均可以用于MultiSubnetFailover=Yes,并且不会影响应用程序的行为。

  • 增加登录超时以适应故障切换时间,减少应用程序的连接重试次数。 驱动程序没有与此设置对应的连接字符串关键字。 连接前通过调用 SQLSetConnectAttr 并带有 SQL_ATTR_LOGIN_TIMEOUT 属性来设置它。

    对于启用自动暂停的 Azure SQL 数据库无服务器,至少使用 60 秒。 自动暂停的数据库会在首次连接尝试时恢复,而该次尝试可能会因数据库正在恢复而失败,并返回错误 40613,因此应用程序必须重试。 更多信息请参见 Azure SQL 数据库 无服务器计算层中的自动暂停和自动恢复。

  • 不支持分布式事务。

如果只读路由不起作用,那么在以下情况下将无法连接到可用性组中的次要副本位置:

  • 如果未将辅助副本所在位置配置为接受连接。

  • 如果应用程序使用 ApplicationIntent=ReadWrite 且将次要副本位置配置为只读访问。

如果将主要副本配置为拒绝只读工作负荷且连接字符串包含 ApplicationIntent=ReadOnly,连接将失败。

指定应用程序意图

你可以在连接字符串中指定 ApplicationIntent 关键字。 可分配的值为 ReadWrite(默认值)或 ReadOnly。

当你设置 ApplicationIntent=ReadOnly 时,客户端将在连接时请求读取工作负荷。 服务器在连接时和在执行 USE 数据库语句期间强制执行此意图。

ApplicationIntent 关键字不适用于旧版只读数据库。

ReadOnly 的目标

如果连接选择 ReadOnly,连接就会分配到数据库可能存在的下列任何特殊配置:

  • AlwaysOn。 数据库可允许或禁止目标可用性组数据库上的读取工作负载。 此选项通过使用 ALLOW_CONNECTIONS 和 PRIMARY_ROLE Transact-SQL 语句的 SECONDARY_ROLE 子句进行控制。

  • Geo-replication

  • 读取横向扩展

如果这些特殊目标都不可用,则会改为从常规数据库读取。

ApplicationIntent 关键字支持只读路由。

只读路由

只读路由是一项功能,可用于确保数据库的只读副本的可用性。 若要启用只读路由,必须遵守以下所有要求:

  • 必须连接到 AlwaysOn 可用性组侦听程序。

  • ApplicationIntent 连接字符串关键字必须设置为 ReadOnly。

  • 数据库管理员必须配置可用性组才能启用只读路由。

使用只读路由的多个连接可能不会全部连接到相同的只读副本。 对数据库同步进行更改或对服务器的路由配置进行更改可能导致客户端连接到不同的只读副本。

你可以确保所有只读请求都连接到相同的只读副本,方法是不将不讲可用性组侦听程序传递到Server连接字符串关键字。 而是指定只读实例的名称。

只读路由可能比连接到主要副本需要更长的时间。 这是因为,只读路由会先连接到主副本,然后再查找最佳可用的可读次要副本。 由于需要执行多个步骤,所以应将 login 超时时间增加到至少 30 秒。

ODBC 语法

有两个 ODBC 连接字符串关键字支持 AlwaysOn 可用性组:

  • ApplicationIntent

  • MultiSubnetFailover

有关 ODBC 连接字符串 关键字的更多信息,请参见“使用 SQL Server 原生客户端的 Connection String 关键字”。

等效的连接属性为:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

有关 ODBC 连接属性的详细信息,请参阅 SQLSetConnectAttr。

使用 AlwaysOn 可用性组的 ODBC 应用程序可以使用以下两个函数之一来建立连接:

Function Description
SQLConnect 函数 SQLConnect 通过数据源名称 (DSN) 或连接属性支持 ApplicationIntent 和 MultiSubnetFailover。
SQLDriverConnect 函数 SQLDriverConnect 通过 DSN、连接字符串关键字或连接属性支持 ApplicationIntent 和 MultiSubnetFailover。