漫谈postgresql的日志实现机制

漫谈postgresql的日志实现机制

 

1、事务的概念

   事务是从实际生活中引入数据库的一个概念，即事务内的操作，要么全做，要么全不做。就像银行转账一样，当从一个帐户转出一部分钱之后，就必须在另一个帐户中存入相同数目的钱，若是转出钱之后，事务中止了，没有在另一个帐户中存钱，那么钱就不翼而飞了，这就是事务的原子性。当事务完成后，必须将其结果记录下来，不然就无从知道事务是已经发生还是尚未发生，这是事务的持久性。此外，事务还有隔离性和一致性。

  www.2cto.com  

2、为什么要引入日志？

   首先，我们了解一下在数据库中是如何实现一个事务的。当事务开始后，我们从磁盘中读取数据，然后对这些数据进行操作，可能是筛选、统计、更新等，还可以有一些新建数据，总之，若发生数据变化后，当数据完成后，必须将这些变化后的数据重新写入到磁盘中，这样我们就完成了一个事务。当然这是最简单的一个描述，下面我们来针对每个环节进行深入的分析。首先是从磁盘中读取数据，根据常识，我们知道，在一个应用系统中，我们可能经常会读取相同的数据，如果每次都从磁盘读取，因为磁盘IO比较慢，所以效率不高，性能不好。大家都能想得到，可以采用缓冲区机制来提高数据读取的性能。
本文主要目的不是缓冲区就不多说了。接下来是对数据的操作，事务完成后，我们需要把更新后的数据写入到磁盘，这里又有同样的问题出现，磁盘IO的性能问题，那么有人说我们还可以用缓冲区机制啊？说的太好了，缓冲区确实帮我们缓解了磁盘IO性能的问题。但缓冲区机制在帮我们解决了磁盘IO性能问题的同时，又带来了一个新的问题，如果发生了故障怎么办？如果数据库系统能千秋万载永世长存的话就没问题了，但现实是不可能的，如果系统发生故障，比如断电、死机什么的，缓冲区中的数据就会丢失，想想你刚中了500W元彩票，结果服务器down机了，你的彩票随着缓冲区的消失随风消逝了，你是不是很想把服务器给啃了？什么？你说你无所谓，一切都是浮云......别告诉我你是火星人......

    我们言归正传，在数据库系统的设计中，数据的丢失是不可接受的，为了解决缓冲区数据写入磁盘的性能问题，引入了日志。在操作数据之前，我们先将操作记入日志，然后再修改数据，当然不修改数据的日志好象没什么意义，这样，即使系统down机导致缓冲区丢失，也不会把500W元彩票化为乌有了。我们可以通过读取日志，重做丢失的数据的操作，就可以保证丢失的数据全部恢复。有人说，写日志与写缓冲区不是一样要写磁盘吗？这位同学说的太对了，真的是一样的，都要进行写磁盘操作，只是有那么一点点细微的差别，写日志是顺序写入磁盘，而缓冲区则是随机写入磁盘。虽然只是这一点点差别，但对性能的影响却是巨大的，有兴趣的同学可以自己去试试哟。此外日志的数据量也远远小于要写入的缓冲区的数据量。
 

    有些人提问了，为什么要先将操作记入日志，然后再执行操作修改数据呢？这是因为若是先执行操作，那么在随后写入日志之前若是系统down机，那么就会丢失此次操作，在数据库系统中称之为WAL(write ahead log)。

  www.2cto.com  

3、日志缓冲区的引入

   为进一步提高性能，引入了日志缓冲区，批量将日志写入到磁盘，而不再是产生一条就写一条，这样又带来一个问题，在日志缓冲区写入磁盘之前有可能会导致日志丢失，从而导致数据丢失。如何解决这个问题呢？我们需要对日志的作用进一步分析，日志是为了重做丢失的操作，若一个事务未提交之前，那么这个事务已进行的操作实际上并不重要，即使丢失也没有什么影响。就像银行转帐一样，从一个账户已经转出，此时系统故障，无法对另一个帐户转入，此事务会回滚，即系统会退回到帐户转出之前的状态，账户转出操作无效，即使账户转出的操作这条日志未被写入磁盘导致操作丢失，当我们恢复时，并不会有什么影响，可能还加速了恢复的过程，少处理了一条日志。因此日志缓冲区的磁盘写入时机可以被推迟，最晚不能晚于事务提交。实际上在日志缓冲区实现上还有一些其它的限制，如checkpoint、日志缓冲区已满等，不一定要等到事务提交时才写入磁盘。