一般来说，对于SQL Server集群这方面的知识大家又有多少了解认识呢？ 如果是新手的话，在SQLServer学习中谈到群集，多少会存在一些误区，因此本期的sql数据库教程学习中将为大家分享几个SQL Server群集的实用方法，在学习SQL server的朋友可以学习一下的。
一、服务器群集采取内置群集功能在Windows Server家族企业版的优势。事实上，对于集群，使用Windows Server2003比Windows 2000高级服务器要好得多。为了使您能够从所获得的集群效益最大化，您需要合适的硬件，而这涉及到一些费用。只有几台服务器使用共享磁盘来拼凑是不够的，你不能依赖于各个硬件组件可能存在于Windows目录（以前称为硬件兼容性列表）的事实。系统作为一个整体必须存在于Windows目录。不过不要担心，也有其他认可的，低成本的集群解决方案。
下图显示了一种典型的群集配置。
Figure 1 A typical cluster
二、集群需要比硬件更多的条件 – 您还需要选择的SQL Server的相应版本2005企业版支持群集功能以及其他一些有用的功能，如能够使用更多的CPU的能力，分布式和可再生能源分区视图，内置日志传送，自动使用索引视图。如果您已经拥有Enterprise Edition许可证，则应考虑群集：您是否有必要的构成二至八个服务器传统的集群（我们将立即讨论了单节点集群）。如果您有SQL Server 2005标准版，您可以安装一个双节点群集。
三、Windows Server 2003 Enterprise Edition和Datacenter Edition 附带内置群集功能。安装群集只需运行群集管理器。您可以同时添加所有节点，也可以每次添加一个节点。类似地，在安装 SQL Server 时，您可以选择安装在单独的非群集服务器上，也可以选择将虚拟实例安装在群集上。如果选择安装虚拟实例，可以安装在群集的所有节点上，也可以安装在一部分节点上，甚至仅安装在一个节点上。
最后，为了达到群集的真正目标，即高可用性，需要为您提供合格的人员以及在出现问题时所遵循的预先演练好的过程。尽管群集是防止出现硬件故障的有力保障，但它无法阻止用户出错。例如，午夜时分，一位睡眼朦胧的DBA删除了一份重要的表。
四、单节点群集
虽然你只有一台服务器的那一刻，你也可以考虑创建一个单节点集群。如果你这样做，你可以在以后选择升级到群集，从而无需重建。但是，请确保你选择的硬件集群节的Windows目录下。
这不只是添加节点来实现，未来这一高可用性的能力。如果你发现你的服务器是不必需的功能，你猜会发生什么。这意味着你需要移动 – 既费时又费力。如果你有一个单节点群集，则迁移过程会更容易，更减少停机时间。您需要将新节点添加到集群，添加SQL Server二进制文件和服务包的新节点，然后故障转移到新节点。接着，更新后添加任何服务包，最后删除旧节点。停机故障恢复时间和增加的只是时间的更新（如果有的话）。
五、添加节点
由于集群中的所有节点都必须是一样的，你应立即（不晚）采取行动，以获得额外的节点。如果等待时间过长，节点可能会退出生产。一旦有这样一个项目，我不得不重新SQL Server 2000群集节点。我所说的操作系统/网络管理员处理了基本的计算机构建，然后我把工作都将重新添加到建成，并准备用作SQL Server节点群集计算机。一切都进行得很顺利，直到我需要故障转移到新节点。不过，我很沮丧，这直接恢复执行。长话短说，尽管我已经准备就如何建立详细的文档，一个新的集群，包括如何将群集服务帐户和SQL Server服务帐户的两个节点，但显然管理员并没有遵循该文档。管理员不添加这些服务帐户重建节点，所以他们有权限之前重建将不复存在。
我花了很长时间才追捕到这个原因。有一天，我突然想到查看一下本地组成员身份。当我添加了这两个帐户之后，故障转移便顺利进行了。于是我开始思考。虽然您只是偶尔才需要重建节点，但如果需要重建节点，那便是在紧急时刻。尽管我已经提供了文档，但人们并不利用它。只需编写一个简短的脚本来添加这两个帐户及进行任何其他必要的自定义，就能使安全部分自动完成。在SQL Server 2005中，事情得到了改善。安装程序要求您为SQL Server服务帐户设置域级组。
当然，这让我想得更多。您可以创建几个脚本，它们调用CLUSTER.EXE将节点添加到Microsoft Cluster Server (MSCS)群集中。您只需为脚本提供节点名称，然后由脚本处理其余工作。在紧急情况下，自动化确实是您的朋友。
六、N+1群集
有时，向群集添加节点的原因不是您要更换节点。您可以将更多的SQL Server实例添加到群集中且每个实例都需要不同的磁盘资源。虽然多个实例可以在一个节点上运行，但这些实例会共享CPU和RAM，因此可能会导致性能降低。理想情况下，在一个节点上仅运行一个实例。但在发生故障转移时如何能确保做到这一点呢？很简单：答案是，有一个节点上不运行任何服务，而其他节点则是每个节点上运行一个SQL Server实例。实际上，这就是N+1群集的定义： N+1个节点上运行N个实例。额外的节点是备用节点。
七、升级SQL Server
升级SQL Server的群集实例不是因为胆小：构建群集只为一个原因 – 您需要正常运行时间。但SQL Server 2005提供了许多您想利用的增强功能。所以，如果您准备升级，无需太多停机时间便可以继续进行。
您会选择哪种方案？我们首先看一看成本最高的解决方案：创建整个新群集。这意味着要创建若干新服务器，或许还要创建新的存储区域网络(SAN)。您或许可以保留现有的网络交换机，但这大约就是您所要保留的全部。显然，这种方法的成本很高，但它具有一定的优势。与旧硬件相比，新硬件的运行通常要好得多，因为磁盘容量和速度都得到了增长。因此，仅仅使用新硬件，您的性能就会得到迅速提高。您甚至可能会租用设备，而这只是为八、了保持领先地位。
硬件到位后，您可以在此安装上创建新的虚拟SQL Server，将生产数据库复制过来，然后考察新系统的性能，从而在移交日期之前留有充足的时间来解决程序错误。但别忘了编写脚本，从现有服务器中退出。（万一发生灾难性故障，最好访问support.microsoft.com/kb/246133来更新登录构建脚本。）
为了将停机时间减到最少，您很可能必须使用日志传送，除非您的数据库相当小并且在一段时间内没有用户建立连接。在移交之前，您都可以正确执行日志传送。接着，删除这些用户，剪切并传送最后的日志，然后指向新实例上的应用程序。（有关感兴趣的日志传送替代方法，请参阅下面的数据库镜像部分。）如果使用DNS别名，您甚至可能不需要指向新实例上的应用程序，而是只需更新 DNS 别名。这种方法的优点是，如果您的迁移只进行了一部分，但必须要回退到原始状态，那您至少还有原始文件。
您还可以使用更便宜的方案，但需要您做更多的预先规划。一个群集可以支持多个SQL Server实例，但每个实例必须有其自己的磁盘资源。因此，当SAN的划分，请留下一个LUN，为未来升级做好准备。要执行升级，在此磁盘资源上安装SQL Server二进制文件。可以锻炼有关系统。当你准备好了，从旧的SQL Server关闭当前的SQL Server，将磁盘资源从小组，更新依赖关系，然后使新SQL Server实例在线。连接的数据库的旧的实例，然后启动和运行。 （你把所有的数据备份早了吧？）
这是一种低成本的方法来实现这个方法需要承担一定的风险。如果发生故障，无法与数据库的新实例分离开并返回到原来的位置。您的操作已简化为从备份恢复 – 这意味着长时间的停机。
另一种方法是对你的SAN的SQL Server的两个实例，假设你有足够的磁盘空间。生产备份（和日志传送）恢复为新实例，然后按照上述进行的步骤。但是，现在你有一个出路。而且，一旦迁移完成后，就可以释放旧实例占用的SAN资源。所有你需要添加额外的磁盘。
九、负载平衡
让我们首先揭穿这样一个常见误解。MSCS群集是用于获得高可用性的，而非用于实现负载平衡。此外，SQL Server没有任何内置的、自动负载平衡功能。您必须通过应用程序的物理设计来实现负载平衡。这意味着什么？
随着表的逐渐增长，您可能会预料到性能会降低，特别是在涉及到表扫描操作时。当行数达到数百万或数十亿时，传统的解决方案会使用已分区视图，这种视图由若干具有相同结构、使用 union ALL 挂接在一起的表组成。此外，还会在适当位置放置 CHECK 约束来区分这些成员表，而这会阻止跨已分区视图复制数据。如果在 CHECK 约束中使用的列也是主键的一部分，则该视图是可更新的。
如果成员表在其自己的文件组中，则如果这些文件组中的文件分别位于不同的物理驱动器上，那么您会获得更佳的磁盘性能。这些表甚至也可以位于不同的数据库中。但是，在SQL Server 2005 中，只要所有数据均在同一个数据库中，您就可以使用表分区，而表分区实现起来就容易得多了。
但是，假设您已经尽可能地利用了表分区或（本地）已分区视图，但性能仍然很低。如果您拥有SQL Server 2000 或SQL Server 2005，就可以利用分布式已分区视图了。主要差别在于，成员表可以位于不同的 SQL Server 实例上，而且这些实例可以安装在 N+1 群集上。为什么鼓励您这样做？如果已分区视图中的任何一个成员表转入离线状态，则整个视图也将转入离线状态。使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性。
十、您真的需要群集吗？
或许您有一些备用服务器无事可做，但这些服务器不在 Windows 目录的群集部分中。如果您在这些服务器可用的情况下，只是为了支持群集就必须出去购置新服务器，那么这是一种浪费可耻的行为。
数据库镜像可能是最适合替代群集的一种方法。镜像涉及到三个元素：存储镜像数据库的实例称为主体；备份服务器称为镜像；如果要实现自动故障转移，还需要第三台服务器，称为见证方。简而言之，主体上的数据库中的事务会在镜像中再次运行。当主体出现故障时，如果有见证方，数据库会自动故障转移到镜像。您必须为每个应用程序数据库设置镜像，但不能镜像系统数据库。
镜像是单独的SQL Server 实例，与群集不同的是，镜像可以位于几千英里以外。其高速缓存中填充的是由于从主体中复制事务而发生的更新活动。当然，还可以假设，除了从主体接收镜像事务之外，镜像上没有其他活动。既然 SQL Server 已经在镜像中运行，所以，故障转移的速度通常要比在群集中快。由于至少有部分高速缓存已准备好，所以，初始性能并不像在群集方案中那样低。另请注意，当镜像数据库发生故障转移时，主体和镜像十一、会互换角色。
数据库镜像的不足之处是，需要的总磁盘容量是群集的两倍。如果您想在同步模式下运行且不想丢失任何数据，那么您还会需要更多的 CPU 处理能力。正如我所说的，要想实现高可用性，需要花费很高的成本。
组合方法
由于镜像与主体之间的距离可以相当遥远，所以对于灾难恢复 (DR) 计划来说，选择镜像是非常明智的。群集是您的第一道防线。但是，如果您要同时利用群集和镜像，那会出现什么情况呢？在群集故障转移中，如果您的镜像配置中有见证方，则当群集 SQL Server 转入在线状态时，镜像会成为主体。但是，请注意，从新主体回到（群集的）新镜像的故障转移不是自动进行的。因此，当与群集结合使用时，最好不要对您的镜像数据库启用自十二、动故障转移。
灾难恢复并不是您使用镜像的唯一原因；当您必须向主体应用服务包或修补程序时，镜像也是非常有用的。在这种情况下，您可以手动故障转移到镜像。在应用服务包或修补程序时，旧的主体服务器暂时处于离线状态，在新主体上发生的已提交事务会排队等候，等待被发送回新镜像（旧主体）。在完成服务包或修补程序的安装之后将会进行同步。最终，这两台服务器将完全处于同步状态。现在您便可以在主体和镜像之间转换角色了。故障转移与恢复只需要几秒钟的停机时间。您可以使用这种方法将 SQL Server 迁移到另一台计算机。只是不能实现故障恢复。
十三、虚拟服务器添加灵活性
虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统。虚拟化软件为群集概念添加了另外一层功能，因为您可以将软件加入群集。因此，如果主机正在其上运行的服务器出现故障，则主机及其来宾 OS 会故障转移到备份节点。这可能是迁移来宾服务器的最简便方法。补充一点，来宾 OS 不必具有群集功能。因此，您可以在运行于某群集中的 Microsoft Virtual Server 2005 之上的来宾 Windows Server 2003 内部运行 SQL Server Workgroup Edition。实质上，您会间接拥有群集 Workgroup Edition
十四、在控制之下
如果您在负责SQL Server实现，你需要确保你的服务器始终可用。服务器群集会帮助确保您的服务器始终可用。本期的sql教程提供了一些来之不易的技巧，以帮助您开始SQL数据库学习更多的技巧。更多的sql数据库视频教程可以登录课课家官网查询相关课程学习的。
