漫谈postgresql的日志实现机制

概述1、事务的概念    事务是从实际生活中引入数据库的一个概念，即事务内的 *** 作，要么全做，要么全不做。就像银行转账一样，当从一个帐户转出一部分钱之后，就必须在另一个帐户中存入相同数目的钱，若是转出钱之后，事务中止了，没有在另一个帐户中存钱，那么钱就不翼而飞了，这就是事务的原子性。当事务完成后，必须将其结果记录下来，不然就无从知道事务是已经发生还是尚未发生，这是事务的持久性。此外，事务还有隔离性和一致 1、事务的概念 事务是从实际生活中引入数据库的一个概念，即事务内的 *** 作，要么全做，要么全不做。就像银行转账一样，当从一个帐户转出一部分钱之后，就必须在另一个帐户中存入相同数目的钱，若是转出钱之后，事务中止了，没有在另一个帐户中存钱，那么钱就不翼而飞了，这就是事务的原子性。当事务完成后，必须将其结果记录下来，不然就无从知道事务是已经发生还是尚未发生，这是事务的持久性。此外，事务还有隔离性和一致性。 2、为什么要引入日志？ 首先，我们了解一下在数据库中是如何实现一个事务的。当事务开始后，我们从磁盘中读取数据，然后对这些数据进行 *** 作，可能是筛选、统计、更新等，还可以有一些新建数据，总之，若发生数据变化后，当数据完成后，必须将这些变化后的数据重新写入到磁盘中，这样我们就完成了一个事务。当然这是最简单的一个描述，下面我们来针对每个环节进行深入的分析。首先是从磁盘中读取数据，根据常识，我们知道，在一个应用系统中，我们可能经常会读取相同的数据，如果每次都从磁盘读取，因为磁盘IO比较慢，所以效率不高，性能不好。大家都能想得到，可以采用缓冲区机制来提高数据读取的性能。本文主要目的不是缓冲区就不多说了。接下来是对数据的 *** 作，事务完成后，我们需要把更新后的数据写入到磁盘，这里又有同样的问题出现，磁盘IO的性能问题，那么有人说我们还可以用缓冲区机制啊？说的太好了，缓冲区确实帮我们缓解了磁盘IO性能的问题。但缓冲区机制在帮我们解决了磁盘IO性能问题的同时，又带来了一个新的问题，如果发生了故障怎么办？如果数据库系统能千秋万载永世长存的话就没问题了，但现实是不可能的，如果系统发生故障，比如断电、死机什么的，缓冲区中的数据就会丢失，想想你刚中了500W元彩票，结果服务器down机了，你的彩票随着缓冲区的消失随风消逝了，你是不是很想把服务器给啃了？什么？你说你无所谓，一切都是浮云......别告诉我你是火星人...... 我们言归正传，在数据库系统的设计中，数据的丢失是不可接受的，为了解决缓冲区数据写入磁盘的性能问题，引入了日志。在 *** 作数据之前，我们先将 *** 作记入日志，然后再修改数据，当然不修改数据的日志好象没什么意义，这样，即使系统down机导致缓冲区丢失，也不会把500W元彩票化为乌有了。我们可以通过读取日志，重做丢失的数据的 *** 作，就可以保证丢失的数据全部恢复。有人说，写日志与写缓冲区不是一样要写磁盘吗？这位同学说的太对了，真的是一样的，都要进行写磁盘 *** 作，只是有那么一点点细微的差别，写日志是顺序写入磁盘，而缓冲区则是随机写入磁盘。虽然只是这一点点差别，但对性能的影响却是巨大的，有兴趣的同学可以自己去试试哟。此外日志的数据量也远远小于要写入的缓冲区的数据量。 有些人提问了，为什么要先将 *** 作记入日志，然后再执行 *** 作修改数据呢？这是因为若是先执行 *** 作，那么在随后写入日志之前若是系统down机，那么就会丢失此次 *** 作，在数据库系统中称之为WAL(write ahead log)。 3、日志缓冲区的引入 为进一步提高性能，引入了日志缓冲区，批量将日志写入到磁盘，而不再是产生一条就写一条，这样又带来一个问题，在日志缓冲区写入磁盘之前有可能会导致日志丢失，从而导致数据丢失。如何解决这个问题呢？我们需要对日志的作用进一步分析，日志是为了重做丢失的 *** 作，若一个事务未提交之前，那么这个事务已进行的 *** 作实际上并不重要，即使丢失也没有什么影响。就像银行转帐一样，从一个账户已经转出，此时系统故障，无法对另一个帐户转入，此事务会回滚，即系统会退回到帐户转出之前的状态，账户转出 *** 作无效，即使账户转出的 *** 作这条日志未被写入磁盘导致 *** 作丢失，当我们恢复时，并不会有什么影响，可能还加速了恢复的过程，少处理了一条日志。因此日志缓冲区的磁盘写入时机可以被推迟，最晚不能晚于事务提交。实际上在日志缓冲区实现上还有一些其它的限制，如checkpoint、日志缓冲区已满等，不一定要等到事务提交时才写入磁盘。 4、lsn的由来和作用 既然已经有了日志，就要发挥它的作用，在恢复过程中，通过读取日志来重做 *** 作，按什么顺序来重做日志呢？记录历史 *** 作的顺序，是非常重要的，如果 *** 作顺序发现混乱，导致的后果也是非常严重的。比如对一个数值100先减去100，再翻倍，若是发生 *** 作顺序逆转，先翻倍再减去100，得到的结果就大相径庭了。这里就需要一个规则，给日志编个序号，我们按日志产生的顺序给每条日志编号，然后按日志编号来重做日志，就不会发生日志重做发生混乱的情况。在实现的过程中，我们在记录日志的时候，是按日志产生的顺序依次写入磁盘的，即使是写到日志缓冲区中，也是按产生的顺序依次写到日志缓冲区，再将日志缓冲区顺序写到磁盘中。因此我们可以采用日志在日志文件中的偏移来代替这个日志编号，不仅不需要额外的磁盘开销，而且还能通过这个偏移迅速定位到这个日志，真是个神奇的想法，我们给这样的日志编号起了一个特殊的名字：lsn，这就是lsn的由来。 但我们又发现一个新的问题，虽然我们知道了所有的历史 *** 作和它们之间的顺序关系，但不知道这些 *** 作的影响是否已经保存到磁盘，如果简单的重做所有 *** 作，会不会把已经做过的 *** 作重复进行。比如购物转账转了两次钱出去？所以在每个数据块的块头记录下最后一次修改这个数据块的 *** 作的日志编号lsn，当重做日志时，数据块加载到缓冲区中，称之为页面，若页面的header中lsn比当前重做日志的lsn小，则说明当前日志尚未被重做； 若不比当前重做日志的lsn小，即大于或等于当前重做日志的lsn，则说明当前日志已经被重做，或不需要重做；通过这种方法，可以避免日志被重复重做，从而得到正确的恢复结果。 5、利用checkpoint加速恢复的过程 当系统发生故障后，由于有日志的存在我们不用担心数据丢失，可以通过读取日志来恢复，但若是系统已经运行了很长时间， *** 作很多，日志很大的情况下，在进行日志恢复时恢复进程会十分慢长。在生产环境下，要求恢复的时间越短越好，怎么才能缩短恢复的时间呢？checkpoint就是解决这个问题的办法。在日志中，引入一种特殊的日志类型，checkpoint日志，它表示在此之前的所有“脏数据”已经写入到磁盘，那么在它之前的日志在恢复过程中就可以忽略掉，而不用再处理。虽然我们希望checkpoint是一个瞬时的过程，但在实现上却有很大的难度，我们不能瞬时将所有“脏数据”写入磁盘，如果可以做到，也就不需要日志了。因此checkpoint是一个过程，有它的起始和结束，当checkpoint开始时，我们记录当前日志的记录偏移lsn，并标记所有的“脏数据”为准备写入状态，接下来就是将具有准备写入状态的”脏数据”写入磁盘，注意：在写入的同时其它进程或线程有可能会产生新的“脏数据”，这些新产生的“脏数据”我们并不关心其是否写入磁盘。当所有已标记的“脏数据”写入磁盘之后，在日志中插入一条checkpoint日志，表示checkpoint已经完成，同时它还记录着checkpoint开始时的日志偏移，也称为REDO偏移。当进行恢复时，首先找到最后一次checkpoint日志的位置，读出checkpoint日志记录，从中获得REDO偏移，然后从REDO偏移开始恢复即可。通过调整checkpoint的间隔时间，可以得到一个可接受的故障恢复时间。 总结

以上是内存溢出为你收集整理的漫谈postgresql的日志实现机制全部内容，希望文章能够帮你解决漫谈postgresql的日志实现机制所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。