背景:
为了简单起见,我们有一个 2 节点集群,其中集群中的每个节点都安装了 3 个 SQL 实例:default + 2 named。我知道实例堆叠不好,我们正在积极摆脱它。这些提到的节点中有 2/3 使用 SQL Server AG(默认和 1 个命名实例),而另一个使用 FCI 进行 DR(最后一个实例并不真正涉及问题,但无论如何添加它)。我们所有的侦听器都使用端口 1433,因为 Microsoft 多年前在迁移期间推荐了这种方法,因为添加非默认端口需要在连接时在侦听器名称中包含端口号。事后看来,我不确定为什么不能在创建时简单地将端口包含在 AG 侦听器中,因为它通过 CNAME 混淆了应用程序。我相信我们没有
问题:
在下面的示例中,当 SQL 的默认实例设置在非默认端口(例如 1400)上时,所有应用程序都按预期连接。但是,当使用默认端口时,所有 CNAMES 都意外地路由到 1433(猜测这是因为侦听器本身在端口 1433 上)。我要确定的是,当用户尝试连接到 1433,但它不存在时,浏览器是否识别出不存在端口 1433 的实例,因此它会执行某种辅助检查/解析逻辑来关联名称侦听器本身是否具有正确的 SQL 实例?
找到了另一个解释这种情况的微软文档,但它未能解释 SQL 如何能够将侦听器 VNN 与实例本身相关联。在我看来,WSFC 资源将该信息与客户端相关联,以确定哪个侦听器路由到哪个实例。但是,如果 1433 上有一个实例,SQL 将不正确地将所有内容路由到该实例,假设所有侦听器出于某种原因都设置在 1433 上。
“侦听器端口配置可用性组侦听器时,必须通过 SSMS 指定一个端口。您可以将默认端口配置为 1433,以简化客户端连接字符串。这意味着,如果您使用 1433,则不会不需要在应用程序的连接字符串中包含端口号。此外,由于每个可用性组侦听器都有一个单独的虚拟网络名称,因此在单个 WSFC 上配置的每个可用性组侦听器都可以配置为引用相同的默认端口 1433 .
如果您将默认端口 1433 用于可用性组侦听器 VNN,您仍然需要确保集群节点上没有其他服务正在使用此端口;否则会导致端口冲突。
如果 SQL Server 的一个实例已经通过实例侦听器侦听 TCP 端口 1433,并且侦听端口 1433 的计算机上没有其他服务(包括其他 SQL Server 实例),这不会导致端口冲突可用性组侦听器。这是因为可用性组侦听器可以在同一进程内共享同一 TCP 端口。但是,不能将多个 SQL Server 实例(并排)配置为侦听同一端口,因为其中一个实例将无法侦听连接。
您还可以指定一个非标准可用性组侦听器端口。但是,在连接到侦听器时,您还需要在应用程序连接字符串中明确使用目标端口。您还需要为此端口在防火墙上打开权限。
您可以使用名称和端口(如果不是 1433)连接到侦听器。该端口可以是侦听器端口,也可以是配置为侦听的基础 SQL Server 端口。”- https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability -group-listener-overview?view=sql-server-ver16
SQL Browser 根本不与可用性组交互。时期。
这是正确的,具有可用性组的非标准端口将需要使用端口号。
对 OP 回答的回应
你错了。
这是错误的,没有其他项目可以在相同的 IP 和端口组合上。这是基本的网络基础知识。您可以使用不同的 IP 地址和相同的端口(参见下面的示例)。
它不是这样工作的。首先,如果尝试绑定相同的 IP/端口组合,则会发生错误。在 SQL Server 中,这通常会抛出错误 10013:
An attempt was made to access a socket in a way forbidden by its access permissions.
其次,由于绑定尝试将失败,因此监听该唯一 IP/端口组合的任何人或任何人仍将具有绑定,因此使用它的任何连接将继续使用它。没有诸如端口、AG、SQL 或其他的“优先级”之类的东西。它像我上面解释的那样工作。
摩擦
这一切都归结为基本的网络和正确的配置。
在下面的屏幕截图中,您可以看到有 3 个实例堆叠在同一台服务器上,所有实例都在 1433 上有一个侦听器,所有这些实例都正确连接。
这需要您正确配置 SQL Server 网络,并且有多种方法可以做到这一点。一种选择是为网络接口提供多个 IP 地址或为每个实例创建一个网络接口。另一种方法是告诉 SQL Server 停止监听所有 IP,只监听一些. 为了显示更好的 SQL Server 配置,并且因为您需要使用第一个选项来执行此操作,所以我以这种方式配置了它。
请注意,我关闭了全部监听并仅启用了我想要的特定 IP。这将删除对 IP ANY 的侦听,然后停止尝试绑定到所有 IP 上每个 AG 的侦听器端口。由于不再有任何
0.0.0.0:1433
绑定,因此不存在冲突,因为每个实例都有唯一的 IP:Port 组合,包括侦听器。为了重申 OP 多个问题的整个症结所在,SQL 浏览器不适用于 AG。CNAME 与端口没有绑定或任何关系。IP:端口组合必须是唯一的,不会发生端口重复魔术(尽管您可以制作套接字复制器和重定向器,但这超出了范围)。
我相信我已经做了足够的研究来更好地了解正在发生的事情,所以我在这里发布我的答案,希望它能使其他人受益。如果我不正确,请告诉我,我会编辑我的答案。
正如 Sean 所说,当通过侦听器连接到 AG 时,SQL 浏览器是无关紧要的。当您的设置涉及同一台机器上的多个SQL 实例,并且侦听器配置为在端口 1433 上运行时,势在必行没有其他服务在端口 1433 上侦听(例如 SQL 的默认实例)。如果启用了 SQL 的默认实例,并且客户端正在连接到使用端口 1433 的侦听器,则会发生端口冲突,因为客户端将导航到主机主(AG 侦听器 IP),然后立即路由到 1433( SQL 的默认实例),因为 SQL 服务端口优先于 AG 侦听器端口。当 SQL 默认实例更改为 1433 以外的端口时,建立连接的客户端再次连接到侦听器 IP,然后使用唯一的 TCP IP 地址 + TCP 端口,它能够正确路由到正确的实例的 SQL。