首页 理论教育分布式数据库故障模型

分布式数据库故障模型

【摘要】:值得一提的是,与数据业务所有者协商十分重要,因为由他们来决定故障恢复过程。故障分类的依据是发生的概率、事件的可预测性和全面影响。表10.1各类故障的或然性、可预测性和冲击●易失存储器信息丢失的故障。日志中包含事务实施的所有动作的undoing或redoing信息。在事务提交后出现故障,则需要redo其操作,目的是保证提交事务的持续性。

参考文献[2]主要讨论MSSQL Server[3]的故障恢复机制。故障恢复过程包含以下几个方面。

●将停摆实例(instance)或服务器返回到一个功能状态的过程。

●将损坏的数据库返回到一个功能状态的过程。

●恢复丢失数据的过程。

●化解停机和数据丢失的风险。

●鉴别开销,包括采取化解步骤或停机/数据丢失的开销。

●对处理和化解步骤的规划和文档进行定级。

●与数据业务所有者协商。

值得一提的是,与数据业务所有者协商十分重要,因为由他们来决定故障恢复过程。

故障分类的依据是发生的概率、事件的可预测性和全面影响。这样,故障可以分为环境类故障、硬件类故障、介质类故障、进程类故障、用户类故障等。

1.环境类故障

环境类故障是指由于服务器所在的环境受到了某种影响,主要包括以下几类。

●服务器机房设计差,如机房通风不佳。

●自然灾害。

●偶发事故,如水管爆裂。

2.硬件类故障

硬件类故障是指服务器、网络设备等出现问题,主要包括以下几类。

主板故障。

●连接线损坏。

●网络故障。

3.介质类故障

硬盘和磁带机的共同特点是使用磁介质,而磁介质比较脆弱,易于损坏。介质类故障主要包括以下几类。

●磁盘驱动器故障。

●主动备份磁带毁坏。

●批量存档磁带毁坏。(www.chuimin.cn)

4.进程类故障

进程类故障主要包括以下几类。

●服务包安装问题:安装服务包时,可能会发送隐含的出错信息,此时,数据库服务器(如SQL Server)不能正常启动。

●人工任务未实施:我们希望某个办公室的某位业务人员的一项工作是定期(每天)备份数据。假设该人员休假而忘了交代给别人做此事,因此问题就出现了。

●自动备份故障:DBA会设置每天晚上9点自动运行备份作业,出错信息也会自动发送给DBA。若该DBA生病多日,当出现故障需要恢复时,除了该DBA外,其他人不知道出现了故障,因此问题就出现了。

5.用户类故障

用户错误很难预测和分类,例如:

●Where is the WHERE:用户忘记在DELETE或UPDATE语句里加入WHERE子句。

●I didn’t delete that:数据录入人员偶然将某客户从数据库删除,由于参考完整性会发生级联的删除,因此将该客户的订单也删除了。

可从各类故障的可预测性(predictability)、或然性(probability)和冲击(impact)三个方面来分析这些故障,如表10.1所示。

可预测性、或然性和冲击三者一起可帮助按照重要性来排列故障恢复计划。如果故障出现的概率低,难于预测,那么影响就小。

从本地恢复看,故障的最大损耗是信息丢失。存储信息是否丢失是信息是否丢失的关键。我们可以将故障归纳为以下几类。

●信息不丢失的故障。这类故障发生时,内存里存放的信息依然可以恢复,如失误夭折(计算时发生内存溢出、除数为零等)。

表10.1 各类故障的或然性、可预测性和冲击

●易失存储器信息丢失的故障。这类故障发生时,虽然内存内容丢失,但是存放在磁盘上的信息不受影响,如系统崩溃。

●非易失存储器信息丢失的故障。这类故障一般称为介质类故障,所以磁盘存储器中的内容也丢失了,如磁盘损坏。从概率上来说,第三类故障出现的概率小于第一类故障和第二类故障。

●更进一步的是稳存的备份信息丢失的故障。

目前针对事务出现故障使用的基本技术是日志(log)。日志中包含事务实施的所有动作的undoing或redoing信息。undo(回退)一个事务的操作意味着去重构操作执行前的数据库。redo(重做)一个事务的操作意味着去重新执行这个操作。

在事务提交前出现故障,则需要undo其操作,目的是保证事务的原子性。在事务提交后出现故障,则需要redo其操作,目的是保证提交事务的持续性。

要注意的是,undo和redo都是满足幂等律的,即如果在undo时发生故障而需要undo恢复操作,甚至在第二次undo时再发生故障,依此类推,一旦正常启动,就只需undo一次;redo同理。因此可以记为:

undo(undo(undo(…(ac t ion)…)))=undo(ac t ion)

redo(redo(redo(…(ac t ion)…)))=redo(ac t ion)