1.1. 工作原理 Windows操作系统和SQL Server的各个节点是通过心跳(heartbeat)信号检查各个节点是否可用的。在操作系统级别上,群集各节点通过持续不断的通讯,检查所有节点的可用情况。当安装完SQL Server容灾群集后,SQL Server虚拟主机通过Service Control Manager每隔5秒检查SQL Server服务是否正在运行,这种检查行为我们称之为LooksAlive,它几乎不影响操作系统的性能,但是这也是一种不彻底的检查。LooksAlive认为只要SQL Server服务状态为可运行时,检查结果即为成功,即使SQL Server服务可能根本无法响应请求。 由于LooksAlive无法彻底检查SQL Server服务的工作状态,每隔60秒还会进行一次IsAlive检查。IsAlive检查机制是通过在SQL Server实例上运行SELECT @@SERVERNAME (T-SQL语句),根据SQL查询返回的结果来决定SQLServer服务是否能够响应请求。尽管IsAlive发出的查询请求可能已经被SQL Server服务正常响应了,但是这并不能判断所有的用户数据库是否都是可用的,其性能是否满足要求。如果IsAlive发出的查询无法成功,它会重试5次,然后尝试重新连接SQLServer实例。如果5次重试全部失败,将认为SQL Server服务失败了。根据SQL Server容灾群集中SQL Server的资源设置,群集将尝试重启服务或在其它节点启动SQL Server服务。IsAlive检查可以容忍查询返回错误的结果,但是如果返回错误结果次数超过设定的阀值,最终还会认为数据库服务已经无法工作了。 当SQL Server实例发生节点转移时,SQL Server的资源将在新的节点上启动。Windows群集在新的节点上启动SQL Server服务,SQL Server服务通过内部恢复进程启动数据库。当SQL Server服务启动,并且master已经联机,SQL Server资源将被认定已经启动。接下来用户数据库将被恢复。那些在事务日志中已经完成的事务将被重用(redo阶段),没有完成的事务将被会退(undo阶段)。SQL Server2005 Enterprise版本的用户数据库,一旦恢复了已提交事务(redo阶段),数据库就可以使用了。对于SQL Server 2005其它版本和早期版本只有当所有未提交事务全部被会退(undo阶段),用户数据库才能使用,这些版本的数据库恢复时间决定于有多少需要回退的未提交事务。 系统参数'recovery interval'可以设定redo恢复的最小时间,通过对其设置可以避免长时间的redo操作进而加速恢复过程。如果想减少undo的恢复时间,需要避免使用长事务。
|