我常常在想,如果数据库不用考虑数据恢复,对我们这些做数据库的人来说,日子也许将变过美好很多。

  没有一种软件会象数据库这样,需要面对如此恶劣的环境。你需要考虑各种可能的错误和故障,例如系统断电、磁盘损坏、甚至是地震火灾。而给你的目标非常明确:不论发生何种故障,数据都不能被丢失,你可能觉得这有些小题大做,可对于许多商业应用(如银行、火车订票系统等)来说,这只不过是最基本的要求。

  要保证每一步操作都不会丢失,既无必要,也无可能(除非你能发明一种和硬盘一样大,和内存一样快,同时断电时数据不丢失的东东)。因此同并发控制中一样,数据库同样也利用了事务的概念。事务是这样一组操作,这组操作要么都做,要么都不做(我们通常把这叫做事务的原子性)。而当你决定结束一个事务时,你可能会选择:是提交(COMMIT)这个事务,还是应该滚回(ROLLBACK)它。如果你选择提交,那么你在这个事务中所做的全部修改都会被存入数据库中,如果这个数据库系统足够强壮,它将保证:只要事务提交完成,不管今后发生何种故障,事务所做的修改都不会丢失。如果你选择滚回,那么系统将回到事务开始的状态,你在该事务中所做的所有修改都将丢失。如果在事务运行当中,系统发生了任何故障,你会期望它的结果应该和你滚回这个事务一样。

  恢复的本质是数据的冗余,在众多的冗余手段中,日志(log)也许是我们最常使用的技术(尽管我们还有许多其它的选择,如影子页面等)。在我们对数据库进行修改之前,系统会将数据修改前的影象(前项)和你要修改的数据影象(后项)保存在日志当中。在这个过程中,有两点需要保证。一是日志必须先于它对应的修改被写入数据库,我们把这叫做先写日志(WAL)协议,这很容易理解,想象一下,如果修改被先写入数据库,而系统在日志被写入之前崩溃了,那么它将无法把该事务恢复到开始的状态。二是在事务提交之前,必须将它的日志写入数据库。否则,系统无法保证后续的故障不会丢失该事务的修改。我们将不能实现我们在前面对用户所做出的承诺。

  我们继续上文的讨论,看看我们到底有哪些故障需要应付。

  首先是应用故障,例如用户不小心错删了一张表,或者应用破坏了完整性约束。这种故障的恢复非常简单,对于前者,你可以显式地滚回事务(利用日志的前项),如果你不小心提交了事务,那么问题就麻烦了,系统也许只能把它当作介质故障(利用备份)来恢复了;对于后者,系统会强迫把该事务滚回。只要数据库还在运行,在系统看来,事务的滚回与其它正常操作并没有什么区别。

  然后是进程故障,假如在系统运行时,一个client崩溃了,或者网络断了(通常服务器无法区别这两种状态);或者服务器端的某个进程死了。这时我们恐怕得为系统配置一个监视进程,由它来定期地检查系统状态,恢复或清除失败的进程(连接),同时把对应的事务滚回。我们会希望这个监视进程是所有进程的父进程,因此假设连它也死了,我们就能把这种情况归结到后面将要讨论的系统故障。

  接着是系统故障,假如系统因为内部错误(例如数据库或操作系统含有bug),或者发生断电。这时缓冲区里的数据全部丢失,但幸运地是磁盘上的数据还在。因此系统在重新启动(RESTART)后,首先重做所有事务的修改(利用日志的后项),这就让数据库回到了发生故障时的状态,这时再将所有在这一点上未提交的事务滚回就完事了。注意这一过程是自动完成的,你完全不需要去关心它。

  再接着是介质故障,假如磁盘出现了坏磁道,或者整个磁盘报销了。这时上面的数据肯定已经丢失了。由于介质故障只能在你试图再次存取磁盘时被发现,而这时故障可能早已发生。因此对介质故障的恢复需要你的参与才能完成。你必须定期地备份(BACKUP)数据库,这样,当介质故障发生时,你可以先用备份重新覆盖整个数据库(RESTORE过程),然后利用日志重做从备份那点到当前的数据库的更新(ROLL-FORWARD过程),接下来的事情就和系统故障完全一样了。你可能会问,那要是日志也坏了怎么办呢?没办法,鸡生蛋、蛋生鸡,总得有个头吧。所以你最好祈祷日志不要坏,为了保证这一点,你应该对日志文件进行镜象,或者干脆用RAID。

  除了这种恢复方式,我们还有一种叫做逻辑恢复的方式,也就是利用我们常常在用的IMPROT/EXPORT工具对数据进行备份/恢复。当然我们只把它看作是介质故障恢复的一种辅助形式(也许它更适合于恢复我们前面说的那种应用故障),因为你只能把数据恢复到你备份的那一点。

  最后是灾难,象发火灾、被人黑了什么的,这时整个系统可能被完全破坏。你当然仍然可以对数据库进行备份,然后把备份(磁盘)放到另一个安全的地方,但这样做,备份以后数据库所做的修改可能就永久丢失了。一个更为稳妥的办法是我们在远程建立一个备份系统,所有在本地产生的日志同时也送往这个远程系统,为了防止网络发生故障,本地与远程系统之间应该同时建立几条相互独立的网络连接。这听上去好象有点超前,可实际上许多关键应用早就用上了。

  应该明白的是,恢复毕竟是一种非常耗时的工作,特别是进行后三种故障的恢复时,数据库对用户不可用。而这对象银行这样的部门来说,损失实在太大了。因此在很多情况下,我们只把恢复看作是最后的一道防线,我们希望最好永远也别需要用到它。因此现在就出来了各种各样的容错设备,象RAID、双机系统什么的,它们会把故障发生的概率降低到一个实际上可能永不发生的程度。


评论

该日志第一篇评论

发表评论

评论也有版权!