Windows环境下ODBC13/17与MultiSubnetFailover多子网集群适配问题

我来逐一拆解并解答你的问题：

1. ODBC 13/17 是否支持 MultiSubnetFailover 关键字及多子网集群环境？ #

完全支持。MultiSubnetFailover 关键字从 ODBC Driver 11 for SQL Server 就已引入，ODBC 13 和 17 作为后续版本，不仅延续了该特性，还优化了对多子网 SQL Server 集群场景的适配能力。

2. 故障转移后无法重连的原因分析 #

你遇到的报错 The connection is broken and recovery is not possible，核心诱因就是设置了 MultiSubnetFailover=No：
当跨子网集群发生故障转移，主节点切换到另一个子网的节点时，MultiSubnetFailover=No 会让驱动沿用传统串行连接逻辑——它不会主动探测集群内的所有子网节点，只会反复尝试连接你指定的旧主节点IP，即使开启重试，也无法定位到新的主节点，最终导致所有恢复尝试失败。

3. 设置 MultiSubnetFailover=No 的预期结果 #

当该参数设为 No 时，驱动会呈现以下行为：

• 采用传统串行连接方式，仅依次尝试连接连接字符串中明确指定的节点（若只写了单个IP，就只会尝试这一个）
• 不会针对多子网集群的故障转移做特殊优化，不会并行探测不同子网的节点
• 连接恢复逻辑仅适配单子网内的故障场景，无法跨子网定位新主节点
• 这种设置更适合单子网集群或者非集群的独立SQL Server实例，此时驱动行为和未配置该参数时一致

4. 多子网集群环境是否推荐设置 MultiSubnetFailover=No？ #

非常不推荐！在多子网集群环境下，MultiSubnetFailover=Yes 才是最优配置：

• 驱动会并行探测集群内所有子网的节点，能快速定位故障转移后的新主节点
• 针对跨子网的连接恢复做了专门优化，大幅提升故障转移后的重连成功率
• 能从根源上避免你当前遇到的连接恢复失败问题

针对你的场景的优化建议 #

修改连接字符串，将 MultiSubnetFailover 设为 Yes，同时建议加入集群所有节点的地址（或使用集群的虚拟网络名称VNN），并适当调整重试参数：

"Driver={ODBC Driver 13 for SQL Server};Server=170.25.132.24,170.25.XXX.XXX;DB=test;USER=abc;PW=XXX;MultiSubnetFailover=Yes;ConnectRetryCount=5;ConnectRetryInterval=10"

• ConnectRetryCount：增加重试次数，给驱动足够时间定位新主节点
• ConnectRetryInterval：设置每次重试的间隔（单位：秒）

内容的提问来源于stack exchange，提问作者Ash