我实际上并没有执行此安装，也不负责解决此特定集群上的问题。我只是碰巧在检查它，发现了一些让我困惑的事情。我的观点是试图理解它为什么起作用，至少在某种程度上是这样。
操作系统：Window Server 2003 Enterprise（64 位）
SQL：SQL Server 2005 Enterprise（64 位）
从 2 节点主动/主动集群开始：Server1 运行 Instance1，然后 Server2 运行 Instance2。
实例 1 和实例 2 位于 SQL Server 2005 的服务包 3 内部版本号（+ 一些修补程序）。我相信它是 9.00.4053。构建了两个新服务器来替换 Server1 和 Server2。所以服务器被构建并添加到集群中，Server3 和 Server4。由于我没有进行安装，因此我假设此人按照 BOL 中所述的步骤添加了新的 SQL Server 节点：http: //msdn.microsoft.com/en-us/library/ms191545( v=SQL.90).aspx
我发现 Instance1 和 Instance2 现在都在 Server3 上运行。然而，实例的内部版本号现在显示为 9.00.1399，这是一个未打补丁的安装。这些实例处于活动状态，并且仍在集群内的 SQL Server 的这个 RTM 版本上运行。？？？？
我在这里的思考过程是，您不能备份 master 数据库并将其还原到内部版本号低于备份来源的实例。因此，如果您只是继续这一点，集群实例如何故障转移到不在同一内部版本号上的节点？为什么 SQL Server（或 Microsoft）甚至允许它这样做？
此外，上面链接的 BOL 文章的最后一步是“故障转移群集实例的所有节点必须处于同一版本级别”。我找不到任何说明如果你不这样做会发生什么。我在 Instance2 上发现的唯一一件事是 SQL 代理作业似乎不再工作了，当数据库联机时，有一个堆栈转储来自 IO 侦听器之类的东西（我不记得显示的确切消息). 我还看到了一些引用 IO 写入问题的消息。
数据库本身是在线的，并且应用程序似乎正在按预期运行。在过去一周左右的时间里，他们一直以这种方式跑步。有什么想法吗？
您可能不需要任何人告诉您需要修复第三个节点上的构建级别！我怀疑一切正常，因为在 SQL2005 中引入了资源数据库：http: //msdn.microsoft.com/en-us/library/ms190940.aspx
我依稀记得我曾经使用过的一个旧的 Windows 2000 / SQL Server 2000 集群，SQL 认为它在一个节点上的补丁级别低于另一个节点。