Sql Server AG 分配了错误的监听器

您的 2014 和 2019 实例都在相同的硬件上运行——只是端口不同。

虽然您没有指定它们使用的端口，但 2014 实例是默认实例，因此它可能在默认端口 (1433) 上运行，而命名实例在其他端口上运行（谁知道......你d 必须检查 SQL Server 配置管理器）。当您连接到命名实例时，SQL 浏览器服务会帮助您解析名称/端口，或者您可以在连接字符串中指定端口。

听起来您的 2019 实例的 AG 侦听器也可能使用非默认端口（您必须检查 SSMS 中的侦听器配置......如果两个侦听器都在端口 1433 上，请继续阅读）。不幸的是，SQL 浏览器服务无法对 AG 侦听器名称发挥作用。

如果您查看相关文档，它会说明使用非默认侦听器端口意味着您需要在连接字符串中包含该端口：

你也可以指定一个非标准的监听端口；但是，这意味着您还需要在连接到可用性组侦听器时在连接字符串中显式指定目标端口。

您应该使用非默认端口吗？在你的情况下，是的。你必须。事实上，如果您在同一个端口上运行两个侦听器，那就是问题所在！文档继续：

如果您为可用性组侦听器 VNN 使用默认端口 1433，您仍然需要确保集群节点上没有其他服务正在使用此端口；否则会导致端口冲突。

在您的情况下，您在同一个集群节点上运行多个服务（SQL 2014 和 SQL 2019）。这会产生冲突，两个sqlservr.exe进程都试图在 1433 上侦听，从而导致端口冲突。在这种情况下，您需要更改其中一个侦听器以使用不同的端口，并在连接时指定该端口（例如，在端口 56789 上连接到 D-AGSQL04-PP，以格式指定服务器名称D-AGSQL04-PP,56789）

侦听器正在使用端口 1436。从“TCP/IP 属性”中，我看到每个实例的 IP 相同，但端口不同。v2014 使用 1433 但 2019 实例使用 1435（应该和监听器一样？）

端口号1433似乎是同样的问题：

当您使用不带端口号的侦听器进行连接时，默认情况下它会尝试在默认端口1433上建立连接。由于侦听器未托管任何 SQL 服务，因此它必须将通信重定向到可用的主副本。当它到达端口号为1433的主副本时

考虑自定义端口在可用性实现中始终是更好的选择（在以下领域中），并且在一个 VM/SERVER 中有多个实例时始终避免端口冲突（使用相同的端口）：

1. SQL 端口（默认值：1433）
2. 端点端口（默认：5022）
3. 侦听器端口（无默认值）