SQLSERVER群集故障转移笔记

出自《SQLSERVER2012实施与管理实战指南》

SQLSERVER故障转移 P41

事实上,从sqlserver2000到sqlserver2008 R2,sqsrvres.dll中定义的looksalive和isalive方法都是类似的。
具体来讲:
looksalive:通过服务器控制管理器(service control manager,SCM)来检查SQLSERVER服务在活跃节点
是否处于“启动状态”。根据SQLSERVER资源的Advanced Polices选项卡中的设置,这个检查默认是
每5秒做一次
 
isalive:根据SQLSERVER资源的Advanced Polices选项卡中的设置,这个检查默认是60秒做一次
也就是说每12次Looksalive检查就会伴随一个Isalive检查。SQLSERVER需要Isalive检查是因为即使
SQLSERVER服务是正在运行状态也不能说明SQLSERVER就可以良好地响应应用程序的请求。有时候
可能整个SQLSERVER已经挂起了,但是服务的状态还是“启动”,所以需要Isalive Check来进一步
检查SQLSERVER的状态。此外,一旦lookalive检查的结果失败,Windows群集服务就会立刻触发
Isalive检查
 
在SQL2012之前,Isalive所做的事情很简单,Windows群集服务会使用TCP/IP或者命名管道来连接
SQLSERVER群集实例。连接上之后,运行一句命令:“select @@servername”。如果成功返回结果
那么Isalive检查就成功了。从第一次成功执行select @@servername开始,Isalive检查就会根据设定
的时间间隔,使用这个连接不断地重复检查工作
 
如果连接不上SQLSERVER群集实例或者语句运行失败,那么Isalive检查失败。此时Windows群集会
再做3~5次(Windows的版本和设置不同)Isalive检查。如果这些检查都失败,就要根据Policies选项卡
中的设置开始进行故障转移
 
你可以把故障转移简单地想象成SQLSERVER服务的重启,所不同的是故障转移的时候,SQLSERVER服务是在
当前节点停止的,然后在另一个节点上启动起来。因此故障转移所花费的时间和SQLSERVER服务重启的时间
是差不多的。当然共享磁盘和虚拟网络名等资源在另一个节点上线也会额外花费一点时间,不过在大多数
情况下这部分时间是比较短的。另外由于故障转移一般是意外发生的,所以你要预期SQLSERVER切换到
新节点以后,还需要一段时间来做数据库的修复
 
前面也提到过,除了SQLSERVER和SQLSERVER AGENT以外,SQLSERVER资源组里可能还会有Analysis Service
资源。但是和SQLSERVER和SQLSERVER AGENT所不同的是,Analysis Service资源没有自己的资源类型,
也就是说他是一个GENERIC SERVICE(通用服务)。Analysis Service的isalive和lookalive检查就使用的是
clusres.dll中定义的通用服务检查方法。
 
 
SQLSERVER的诸多组件和服务中,SQLSERVER 、SQLSERVER AGNET、ANALYSIS SERVICE三个服务
无论是有自己专属的资源类型还是通用服务,都是被设计为可以通过resource dll形成群集资源。
这种类型的服务被称为cluster-aware。SQLSERVER还有很多其他资源,比如:SQL broswer、Reporting Service
等,他们被设计为无法通过任何resource dll在Windows群集中形成资源,所以他们不是cluster-aware的。
对于不是cluster-aware的服务,即使被安装在了群集的节点上,Windows依旧把他当成是安装在了一个
单机环境中,他无法具有故障转移的功能。
 
需要提一下的是Integration Services是一个比较特别的服务。Integration Services本身不是cluster-aware的服务
,但是用户可以通过一些步骤手动把他配置成一个群集资源。但是这样配置出来的Integration Services群集
资源不是一个真正的资源,是不具有自动故障转移功能的,因此微软并不推荐这麽做。
更多信息,参考
Configuring Integration Services in a Cluster
 
 
2.2.4 SQLSERVER群集的拓扑结构
最简单的SQLSERVER故障转移群集拓扑结构就是“活跃/非活跃 ”群集,这种结构
下群集有两个节点,用户在群集上安装一个SQLSERVER群集实例,该实例的“可能的所有者(Possible Owners)”
包含上述两个节点。这样任意时间只有一个节点上有SQLSERVER服务在运行,而另一个节点就是“非活跃”
节点。这种配置优点就是结构简单明了,无论SQLSERVER运行在哪个节点上都能获得同样的性能表现。
缺点是总有一个节点处于空闲状态,浪费了50%的硬件资源
 
另一种拓扑结构是活跃/活跃集群,还是以一个两节点的群集为例,这个时候用户在群集上安装两个SQLSERVER
群集实例,每个实例的“可能的所有者”都包含群集两个节点。在正常情况下,两个实例分别运行在不同的节点上,
这样两个节点就都是“活跃”节点
这种结构的优势是:两个节点的硬件资源都能被充分利用(需要安装两个或多个SQLSERVER群集实例),并且节约成本。
缺点是:一旦某个节点发生故障转移,就会发生另一个节点上同时运行了两个SQLSERVER实例的情况。此时,这两个
实例可能会争用这个节点上的CPU、内存、I/O等资源,导致两个实例的性能都受到影响。有时可能两边的用户都不能
接受。因此要尽快解决异常节点上的问题,尽早把发生故障转移的实例切换回去
 
在此基础上,我们来介绍所谓的N+1结构,即N个活跃节点加上一个非活跃节点,以3个节点的群集为例
在上面安装两个SQLSERVER群集实例,每个实例的Possible Owner包含群集中的两个节点,但是只有
一个节点是两个实例共有的。正常情况下,两个SQLSERVER都运行在非共有的那个节点上,互不相干
。一旦某个节点发生故障转移,就会切换到那个共有的非活跃节点上
这个结构是一个介于“活跃/非活跃”和“活跃/活跃”之间的一种方案。相对于“活跃/非活跃”,
他浪费的节点资源比较少(1/N+1)。另外,两个以上的节点同时发生故障转移,需要同时切换到
共有节点的概率是比较低的,因此也在一定程度上解决了“活跃/活跃”结构的性能问题
 
无论什么样的拓扑结构,有两点是不会变的:
1、SQLSERVER集群无法提供数据库端的负载均衡功能。作为“活跃/活跃”群集,其实是几个
独立的数据库实例,他们彼此间没有联系。再次强调,群集技术只是一个提供“高可用性”的技术
,而不是提升性能的技术
 
 
2、无论群集有几个节点,对于某个数据库实例而言他只有一份数据一旦数据本身出现问题,群集
对此便无能为力。所以,群集技术不是一个提供数据“灾难恢复”的技术。对重要的数据库,仅仅使用群集技术是不够的
 
2.2.5 SQL2012对故障转移群集的改进
SQLSERVER2012群集基本沿袭了SQLSERVER2008群集以来的一系列特点。不过他也带来了一些新特性
使得群集具有了更加强大的功能以及更高的可用性。
新特性介绍
1、多子网群集的支持
2、RegisterAllProvidersIP
3、存放数据库的物理位置
4、新的Resource DLL
5、Sp_server_diagnostics
 

SQLSERVER群集故障转移笔记的更多相关文章

  1. AlwaysOn可用性组功能测试(二)--SQL Server群集故障转移对AlwaysOn可用性组的影响

    三. SQL Server群集故障转移对AlwaysOn可用性组的影响 1. 主副本在SQL Server群集CLUSTEST03/CLUSTEST03上 1.1将节点转移Server02.以下是故障 ...

  2. 基于iSCSI的SQL Server 2012群集测试(四)--模拟群集故障转移

    6.模拟群集故障转移 6.1 模拟手动故障转移(1+1) 模拟手动故障转移的目的有以下几点: 测试群集是否能正常故障转移 测试修改端口是否能同步到备节点 测试禁用full-text和Browser服务 ...

  3. Sqlserver实现故障转移 — sqlserver镜像备份实现故障转移(3)

    目的:在已经加域的计算机上安装sqlserver2012,并配置数据库镜像实时同步,并实现故障转移. 在数据库层面实现故障自动转移后,应用程序里改怎么写数据库连接呢?其实使用ADO.NET或者SQL ...

  4. Sqlserver实现故障转移 — 域控(1)

    一  .实现目的:实现两台sqlserver数据库服务器的实时备份及故障转移:即:其中一台数据库服务器宕机后,应用程序可自动连接到另一台数据库服务器继续运行. 二.域控:域控制器是指在“域”模式下,至 ...

  5. Sqlserver实现故障转移 — AlwaysOn实现故障转移(4)

    目的:在已经加域的计算机上安装sqlserver2012,并配置系统级故障转移及数据库,实现AlwayOn. 域控的建立详见:https://www.cnblogs.com/xiaoerlang90/ ...

  6. Sqlserver实现故障转移 — 加域(2)

    目的:将计算机添加到域中, 域控的建立详见:https://www.cnblogs.com/xiaoerlang90/p/9224745.html 域控: 名称:dcTest.com IP: 192. ...

  7. SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败

    原文:SQLServer 2012异常问题(一)--故障转移群集+镜像环境导致作业执行失败 先感谢一下我的同事们最先发现此问题,鸣谢:向飞.志刚.海云 最近在生产环境发现一个诡异的问题: 环境:WIN ...

  8. 搭建Windows故障转移群集

    标签:SQL SERVER/MSSQL SERVER/数据库/DBA/windows 概述 本章内容主要讲述搭建windows故障转移群集 环境: 域服务器:windows server 2008 R ...

  9. Hyper-V 2012 R2 故障转移群集

    和终端用户相比,企业用户对于业务的连续性和可靠性更为在意.相对而言,企业一般不会将追逐单一硬件的性能排在第一位. 如何衡量业务是否持续可用,一般使用"x 个 9"这种方式来定义.如 ...

随机推荐

  1. Java多线程-Callable的Future返回值的使用

    一般使用线程池执行任务都是调用的execute方法,这个方法定义在Executor接口中: public interface Executor { void execute(Runnable comm ...

  2. Vue笔记:VS Code 常用快捷键

    VS Code 常用快捷键 1.注释: 单行注释:ctrl+/, 注释后再按取消 取消单行注释:alt+shift+A 注释后再按取消 2.移动行 向上移动一行:alt+up 向下移动一行:alt+d ...

  3. Tensorflow应用之LSTM

    学习RNN时原理理解起来不难,但是用TensorFlow去实现时被它各种数据的shape弄得晕头转向.现在就结合一个情感分析的案例来了解一下LSTM的操作流程. 一.深度学习在自然语言处理中的应用 自 ...

  4. webkit技术内幕读书笔记 (四)

    资源缓存 资源缓存的目的是为了提高资源使用的效率,其基本思想是建立一个资源的缓存池,当需要请求资源的时候先去资源池查找是否有相应的资源,如果没有则向服务器发送请求,webkit收到资源后将其设置到该资 ...

  5. tomcat 启动速度慢背后的真相

    1. tomcat 启动慢 在线上环境中,我们经常会遇到类似的问题,就是tomcat 启动比较慢,查看内存和cpu,io都是正常的,但是启动很慢,有的时候长达几分钟,这到底是什么原因导致的. 1.1 ...

  6. mybatis插入数据库 返回主键

    传递参数为对象TaskEntity, 返回主键结果为Integer 与 主键 task_id 的类型一致即可 <insert id="addTask" parameterTy ...

  7. ansible 角色登陆

    用ansible 来管理远程的主机,最大的好处是方便,ansible不用在远程的主机上安装ansible的客户端,ansible只要能通过ssh连接上远程主机就 能对它进行管理.也就是说ansible ...

  8. 合并两个数组并去重(ES5和ES6两种方式实现)

    合并两个数组并去重(ES5和ES6两种方式实现) ES6实现方式 let arr1 = [1, 1, 2, 3, 6, 9, 5, 5, 4] let arr2 = [1, 2, 5, 4, 9, 7 ...

  9. 浅谈sql中的in与not in,exists与not exists的区别以及性能分析

    1.in和exists in是把外表和内表作hash连接,而exists是对外表作loop循环,每次loop循环再对内表进行查询,一直以来认为exists比in效率高的说法是不准确的.如果查询的两个表 ...

  10. sqlserver C# 数据类型对照表(转载)

    数据库中字段类型对应C#中的数据类型: 数据库                 C#程序 int int32 text string bigint int64  或 longbinary System ...