|
对于需要持久化数据的软件或者系统，必须要解决的问题是如何处理意外中断导致的数据丢失问题。比如一个交易系统，用户正在购买商品，突然断电了，那么如何恢复用户的账户信息？该不该扣款？商家的商品到底有没有卖出？这一些列的问题需要数据库恢复机制解决。 而恢复机制需要借助日志系统才能展开。日志记录了系统中发生的各个事务。基本的思路就是，把事务提交至数据库的同时，也在日志文件中记录一下。那么应该先提交事务，还是先记录事务的日志？粗略地讲，必然是先提交日志，因为如果先提交事务，正好提交了一半断电，这个事务只执行了一半，由于没有日志记录，所以根本无法获取这个事务的执行情况，比如执行了哪些操作，哪些操作还未执行，因此也就无法恢复事务。所以在提交事务之前，必然要先提交日志。 有了数据库事务的日志，然后是两个必要的操作： 1.redo：就是重做，指的是按照日志上的操作记录重做，而不是重做事务，虽然结果一样，但是日志上记录的是cpu计算得到的最终结果，因此效率更高。 2.undo：就是撤销，或者回滚，指的是把日志上记录的操作撤销，恢复到原本的值。 因此，日志的一条记录必然包括操作类型，原始值，更新值这三种信息。这样才能进行redo和undo。还有一种是commit点，就是表明某一个事务已经结束。 恢复技术可以分成两种类型： 1，延迟更新 事务达到了commit点，被提交，然后先把事务的日志记录到数据库以后，才把事务更新到数据库。 这种情况下，如果在日志中没有看到某一个事务的commit点，那么说明该事务的日志还没有完全被记录到数据库，那么这个事务的操作也一定没有更新到数据库中，因此，这个事务一定没有被执行。如果有了commit点，这个事务可能被完全执行，可能被执行了一部分，也可能没有执行。那么我们只需要重做一次事务的操作即可。认为这个事务已经执行。 2，立即更新 事务不需要到达commit点就可以更新到数据库，但是操作被更新前必须先记录日志。比如事务包含4个操作才是commit，那么不需要等到commit，第一个操作就可以执行，但是必须在日志更新后。 这种情况下，对于日志中有commit的事务，全部redo，日志提交了，但是操作可能没有更新，所以redo。但是对于没有commit的事务，一定没有全部执行，可能只执行了一部分，由于日志不全，也无法做redo，只能undo。即把日志中该事务的操作全部undo，取消部分更新带来的影响。 |
|
|
