我刚开始新的工作，发现安装在 Core Server 2012 R2 上的两个 SQL 2012 (SP2) 实例的名称与其运行的服务器名称不同。它们都是虚拟服务器。例如，服务器名称是 Server2 和 Server3（可以通过 RDP 连接到它，并且可以使用此名称以多种方式连接到它）甚至可以从其他机器连接到 SSMS。但是，当我运行@@Servername 时，它会在两台服务器上返回“CO-SQLTEMPLATE”。之所以麻烦，是因为这两个实例参与了AlwaysOn复制，有几个问题……最明显的一个是自动备份不行。使用 HADR 系统表和函数，它要么表明没有任何副本是“主要的”，要么所有副本都是（！！！）。此外，尚不清楚复制是否真的有效。
我一直在谷歌上四处寻找，但找不到指示 SQL Server 在安装过程中从何处获取其实例名称的来源。我以前从未见过这个问题，这确实很奇怪。
这是我在清理 2 台服务器并从头开始（显然，我宁愿不这样做）之前尝试找到解决方案的最后努力。
听起来有人认为创建可以克隆的“首选”SQL Server VM 很容易。没有人愿意更改标准的 CO-SQLTEMPLATE SQL Server 名称。如果复制确实在工作，我会质疑它是否正常工作，因为 SQL Server 名称应该与 VM/物理服务器名称相匹配——减去实例。更糟糕的是，人们可能使用虚拟机/物理名称连接到 SQL Server 而不知道 CO-SQLTEMPLATE。
如果您不打算销毁和重建，您可能需要重命名 SQL Server 以匹配其安装位置的 Windows Server 名称：
我不相信那个 SQL Server 设置。如果可以的话，我会检查可用性组文件夹，看看复制的数据库是 myDB（主）还是 myDB（辅助）。然后在带有 myDB（主）的服务器上中断并重建 AlwaysOn 复制，并使用 AlwaysOn 向导重建复制。（但是，我没有使用向导添加侦听器，因为那部分对我来说似乎有问题。我单独添加了侦听器）。
但在此之前，如果服务器像你说的那样混乱，我会通过故障转移管理器验证 Windows 集群是否正常工作。并且，验证 DNS 是否确实包含您的 Windows 服务器和您的侦听器（可能还有见证人）的名称——如果您有的话。
警告：当用户连接到两个不同服务器上的 CO-SQLTEMPLATE 的两个实例时，您的服务器甚至可能比您想象的更糟糕，因为它们都“可能”代表两个完全不同的数据集并且完全不相关。因为，毕竟，他们使用了方便的 VM 模板来使他们的 SQL Server 生活更轻松。