知识大全几个技巧解析SQL Server群集的难题[2]

Posted 2022-07-15 主体

篇首语：少年辛苦终身事，莫向光阴惰寸功。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全几个技巧解析SQL Server群集的难题[2]相关的知识，希望对你有一定的参考价值。

几个技巧解析SQL Server群集的难题[2] 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　为了将停机时间减到最少您很可能必须使用日志传送除非您的数据库相当小并且在一段时间内没有用户建立连接在移交之前您都可以正确执行日志传送接着删除这些用户剪切并传送最后的日志然后指向新实例上的应用程序 (有关感兴趣的日志传送替代方法请参阅下面的数据库镜像部分 )如果使用DNS别名您甚至可能不需要指向新实例上的应用程序而是只需更新 DNS 别名这种方法的优点是如果您的迁移只进行了一部分但必须要回退到原始状态那您至少还有原始文件

　　您还可以采用一种成本较低的方案但需要您做更多的预先规划一个群集可以支持多个SQL Server实例但每个实例必须有其自己的磁盘资源因此在划分SAN时请留出一个LUN 以备将来升级要执行升级请在此磁盘资源上安装 SQL Server 二进制文件您可以演习一下该系统当您准备好后关闭当前SQL Server 将磁盘资源从旧的 SQL Server组中移出更新依赖关系然后使新SQL Server实例在线连接旧实例中的数据库然后启动并运行 (您已提早备份了所有数据对吗?)

　　这就是成本较低的方法实行这个方法需要承担一些风险如果出现故障您无法将数据库与新实例分离开来并放回原来位置您的操作已简化为从备份恢复这意味着需要很长的停机时间

　　还有一种方法是将两个SQL Server实例都放在您的SAN中前提是您有足够的磁盘空间将生产备份(和日志传送)恢复为新实例然后按前面介绍的步骤继续进行但现在您有退路了而且一旦完成迁移您还可以释放旧实例占用的SAN资源您只需增加额外的磁盘

　　负载平衡

　　让我们首先揭穿这样一个常见误解 MSCS群集是用于获得高可用性的而非用于实现负载平衡此外 SQL Server没有任何内置的自动负载平衡功能您必须通过应用程序的物理设计来实现负载平衡这意味着什么?

　　随着表的逐渐增长您可能会预料到性能会降低特别是在涉及到表扫描操作时当行数达到数百万或数十亿时传统的解决方案会使用已分区视图这种视图由若干具有相同结构使用 union ALL 挂接在一起的表组成此外还会在适当位置放置 CHECK 约束来区分这些成员表而这会阻止跨已分区视图复制数据如果在 CHECK 约束中使用的列也是主键的一部分则该视图是可更新的

　　如果成员表在其自己的文件组中则如果这些文件组中的文件分别位于不同的物理驱动器上那么您会获得更佳的磁盘性能这些表甚至也可以位于不同的数据库中但是在SQL Server 中只要所有数据均在同一个数据库中您就可以使用表分区而表分区实现起来就容易得多了

　　但是假设您已经尽可能地利用了表分区或(本地)已分区视图但性能仍然很低如果您拥有SQL Server 或SQL Server 就可以利用分布式已分区视图了主要差别在于成员表可以位于不同的 SQL Server 实例上而且这些实例可以安装在 N+ 群集上为什么鼓励您这样做?如果已分区视图中的任何一个成员表转入离线状态则整个视图也将转入离线状态使这些成员成为群集的一部分可以为您提供支持性能和实现负载平衡所需的可靠性

　　您真的需要群集吗?

　　或许您有一些备用服务器无事可做但这些服务器不在 Windows 目录的群集部分中如果您在这些服务器可用的情况下只是为了支持群集就必须出去购置新服务器那么这是一种浪费可耻的行为

　　数据库镜像可能是最适合替代群集的一种方法镜像涉及到三个元素存储镜像数据库的实例称为主体;备份服务器称为镜像;如果要实现自动故障转移还需要第三台服务器称为见证方简而言之主体上的数据库中的事务会在镜像中再次运行当主体出现故障时如果有见证方数据库会自动故障转移到镜像您必须为每个应用程序数据库设置镜像但不能镜像系统数据库

　　镜像是单独的SQL Server 实例与群集不同的是镜像可以位于几千英里以外其高速缓存中填充的是由于从主体中复制事务而发生的更新活动当然还可以假设除了从主体接收镜像事务之外镜像上没有其他活动既然 SQL Server 已经在镜像中运行所以故障转移的速度通常要比在群集中快由于至少有部分高速缓存已准备好所以初始性能并不像在群集方案中那样低另请注意当镜像数据库发生故障转移时主体和镜像会互换角色

　　数据库镜像的不足之处是需要的总磁盘容量是群集的两倍如果您想在同步模式下运行且不想丢失任何数据那么您还会需要更多的 CPU 处理能力正如我所说的要想实现高可用性需要花费很高的成本

　　组合方法

　　由于镜像与主体之间的距离可以相当遥远所以对于灾难恢复 (DR) 计划来说选择镜像是非常明智的群集是您的第一道防线但是如果您要同时利用群集和镜像那会出现什么情况呢?在群集故障转移中如果您的镜像配置中有见证方则当群集 SQL Server 转入在线状态时镜像会成为主体但是请注意从新主体回到(群集的)新镜像的故障转移不是自动进行的因此当与群集结合使用时最好不要对您的镜像数据库启用自动故障转移

　　灾难恢复并不是您使用镜像的唯一原因;当您必须向主体应用服务包或修补程序时镜像也是非常有用的在这种情况下您可以手动故障转移到镜像在应用服务包或修补程序时旧的主体服务器暂时处于离线状态在新主体上发生的已提交事务会排队等候等待被发送回新镜像(旧主体) 在完成服务包或修补程序的安装之后将会进行同步最终这两台服务器将完全处于同步状态现在您便可以在主体和镜像之间转换角色了故障转移与恢复只需要几秒钟的停机时间您可以使用这种方法将 SQL Server 迁移到另一台计算机只是不能实现故障恢复

　　虚拟服务器添加灵活性

　　虚拟化允许您在一台物理服务器上并行运行一个或多个操作系统虚拟化软件为群集概念添加了另外一层功能因为您可以将软件加入群集因此如果主机正在其上运行的服务器出现故障则主机及其来宾 OS 会故障转移到备份节点这可能是迁移来宾服务器的最简便方法补充一点来宾 OS 不必具有群集功能因此您可以在运行于某群集中的 Microsoft Virtual Server 之上的来宾 Windows Server 内部运行 SQL Server Workgroup Edition 实质上您会间接拥有群集 Workgroup Edition

　　在控制之下

　　如果您在负责 SQL Server 实现您需要确信您的服务器始终处于可用状态服务器群集会帮助确保您的服务器始终可用本文提供了一些来之不易的技巧以帮助您入门您可以在群集资源边栏中找到更多有用信息

cha138/Article/program/SQLServer/201311/22476

知识大全 几个技巧解析SQL Server群集的难题[2]

知识大全几个技巧解析SQL Server群集的难题[2]