关于SQL Server 群集的几个关键技巧

核心提示： 最后，为了达到群集的真正目标，关于SQL Server 群集的几个关键技巧(2)，即高可用性，需要为您提供合格的人员以及在出现问题时所遵循的预先演练好的过程，管理员没有将这些服务帐户添加到重建节点，所以，尽管群集是防止出现硬件故障的有力保障，但它无法阻止用户出错

最后，为了达到群集的真正目标，即高可用性，需要为您提供合格的人员以及在出现问题时所遵循的预先演练好的过程。尽管群集是防止出现硬件故障的有力保障，但它无法阻止用户出错。例如，午夜时分，一位睡眼朦胧的DBA删除了一份重要的表。

单节点群集

尽管您在此刻只拥有一台服务器，也可以考虑创建一个单节点群集。如果这样做，您可以在以后选择升级到群集，从而无需重建。但是，请务必确保您所选择的硬件位于 Windows目录的群集部分。

这样做不仅仅只是为了实现能够在以后添加节点这个高可用性。如果您发现您的服务器恰好没有必需的功能，那么您猜会发生什么事情。这意味着您需要迁移 - 既费时又费力。如果您有一个单节点群集，则迁移过程就会变得很容易，停机时间也少得多。您需要向群集中添加新节点，将SQL Server二进制文件和服务包添加到该新节点，然后故障转移到该新节点。接下来，添加任何服务包之后的更新程序，最后删除旧节点。停机时间只是故障转移时间与添加更新程序（如果有）时间之和。

添加节点

由于一个群集中的所有节点必须相同，您应该立刻（而不是稍后）采取行动，获得另外的节点。如果等待时间太长，节点可能会退出生产。曾经就有这样一个项目，我不得不在 SQL Server 2000群集中重建节点。我请操作系统/网络管理员处理了基本的计算机构建，然后我投入工作，将构建的计算机添加回群集并准备将其用作 SQL Server 节点。一切都进行得很顺利，直到我需要故障转移到新节点。但令我非常沮丧的是，它却直接执行了故障恢复。长话短说，尽管我已经准备了有关如何构建新群集的详细文档，其中包括如何将群集服务帐户和SQL Server服务帐户添加到这两个节点，但显然管理员并没有遵循该文档。管理员没有将这些服务帐户添加到重建节点，所以，他们在重建之前所拥有的权限便不再存在。