Freigeben über

了解群集环境下的数据库高级属性

  • Artikel

【介绍】

在群集环境下，数据库资源有一些属性。深入了解数据库资源的属性，对于我们更好的管理群集下的数据库，有很大的帮助。我们这里介绍一个公共的属性和特有的属性。并且试验这些属性。这里以Windows 2003 群集环境为例。

【是否Restart】

这个属性设定是，当数据库资源Failed的时候，是否会去尝试重新启动。在群集环境下，这个属性要设为Restart。这样，当资源失败的时候，它会尝试去重启或迁移到另外一个组。

测试 => 当我们选择 “Do not restart”，右键点击SQL Server资源，并选择”Initiate Failure”，那么该SQL Server资源会直接Fail。这样就失去了群集的意义了。所以这个选项我们要选择”Restart”

【影响组 】

这个属性设定是，当SQL Server (MYINSTANCE)资源出现错误的时候，是否会影响到整个组。因为Failover是针对整个组而言，所以如果不会影响组的话，则该资源还是无法Failover到另外一个组。

测试 =>

1.       我们在”Affect the group” 上不打勾。

2.       然后在任务管理器里，把SQL Server的进程杀掉。

3.       我们会观察到，该资源会一直处于Fail的状态。

4.       现在我们把”Affect the group” 打勾，那么做同样的操作时，首先SQL Server (MYINSTANCE)会fail，接着，整个组里的所有其他资源会受到影响，全部Offline, 然后Failover到另外一个节点上，在另外一个节点上，资源能够正常上线。

【Threshold和Period】

这两个属性的缺省值为3和900，也就是说，在900秒，也就是如果某资源失败，则会在15分钟内，去本节点上尝试重新ONLINE三次。三次不成功，则失败(如果没有选择Affect the group)或开始做FAILOVER(如果选择了Affect the group)。

 

测试 =>

1.       为简单起见，我们把该值改为10秒内3次。以方便重现问题

2.       在”Affect the group” 上不打勾。

3.       把SQL Server (MYINSTANCE) 资源Offline

4.       到共享磁盘上，把master.mdf 改名为master.mdf.bak

5.       这时候，我们尝试去Online SQL Server (MYINSTANCE)，第一次会失败，因为找不到master.mdf, 接着群集会在该结点上再尝试三次，发现还是不能ONLINE，这时候，该资源会一直处于失败状态。

6.       我们把该值改为1秒内3次。在这种设置下，我们会发现SQL Server (MYINSTANCE)会不间断的一直尝试去重启。这是因为启动SQL Server需要时间，在一秒内，不能完成三次启动的尝试，所以在下一秒，又开始重新计数。

【LOOKSALIVE和ISALIVE检查】

LOOKSALIVE检查比较简单，群集会去检查SQL Server这个服务的状态，确认SQL Server这个服务的状态处于RUNNING。

而ISALIVE会做更进一步检查，它会连接到数据库里面，执行一条很简单的查询，明确该查询能返回，就说明数据库状况是正常的。

缺省状况下，LOOKSALIVE每隔5秒做一次，而ISALIVE则每隔60秒做一次检查。

测试 => 我们打开SQL Profiler, 会发现每隔一分钟，从群集那里会有一个查询SELECT @@servername发过来。同时，我们会发现，我们的连接是一直保持着的。

 

我们也可以做另外一个测试，

1.       建立一个alias, 把MYSERVER\MYINSTANCE 映射到一个不存在的服务器上

2.       在查询中，把从群集过来的连接KILL掉，（必须要这样做，否者连接没有断掉，还是用MYSERVER\MYINSTANCE）

这时，我们就会发现，ISALIVE检查会失败。因为群集无法连到数据库上。MYSERVER\MYINSTANCE已经被重定向了。 

【PENDING TIMEOUT】

要注意的是，这里的PENDING TIMEOUT并不是资源在ONLINE PENDING或OFFLINE PENDING的最长时间，事实上，SQL Server 可以超过PENDING TIMEOUT时间而一直处于ONLINE PENDING或OFFLINE PENDING状态。我们知道，每个资源都有一个Resource Monitor（资源管理器）。这里的PENDING TIMEOUT是群集询问资源管理器，资源管理器如果在PENDING TIMEOUT时间内没有回复，则群集会通过资源管理器调用Terminate函数把该资源强制OFFLINE。如果资源管理器在PENDING TIMEOUT时间内有回复，则资源可以继续处在ONLINE PENDING或OFFLINE PENDING状态。群集会在下一轮时间内，继续查询资源管理器， 而不是资源本身。

 

测试 => 我们把SQL Server (MYINSTANCE)的PENDING TIMEOUT 改为10秒。然后把SQL资源OFFLINE再ONLINE, 我们会发现SQL Server处于ONLINE PENDING超过了10秒，再过几秒，还是能成功处于ONLINE状态了。这是因为在ONLINE PENDING的过程中，资源管理器还是有响应的。

【SQL 特有属性】

SQL Server 在群集环境下，如果做了一次FAILOVER，要找为什么会FAILOVER，在某些情况下会非常困难，因为问题不能重现，为了能够更好的调查FAILOVER的原因，SQL资源有一个特有的属性。也就是在FAILOVER发生的时候，对SQL Server收集一个Memory Dump，以供我们调查在FAILOVER时，当时SQL Server的状态。该属性可以用下面的语句查询得到:

 

Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpFlags=0x8100

Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpPath=”C:\TEMP”

Cluster res “SQL Server (MYINSTANCE)” /priv SQLDumperDumpTimeOut=300000

 

测试 =>

1.       我们执行上面的命令，把特有属性设好

2.       我们建一个alias, 把MYSERVER\MYINSTANCE重新定向到一个不存在的服务器名

3.       查询 SELECT * FROM sys.sysprocesses 得到Cluster连数据库的SPID

4.       KILL 51  这里51是cluster连数据库的SPID

5.       过一会儿，ISALIVE检查失败，SQL资源会做FAILOVER, 同时在C:\Temp目录，我们会看到filter dump产生。

【总结】

我们讨论了SQL Server在群集中的一些属性。了解这些属性，对于我们理解在群集环境下，SQL Server的行为是非常有帮助的。我们需要正确的设置这些属性，使得SQL Server能够在群集环境下，正常的工作。