(1)
lsn 由来
(来自:http://blog.csdn.net/xabc3000/article/details/7658439)
既然已经有了日志,就要发挥它的作用,在恢复过程中,通过读取日志来重做操作,按什么顺序来重做日志呢?记录历史操作的顺序,是非常重要的,如果操作顺序发现混乱,导致的后果也是非常严重的。比如对一个数值100先减去100,再翻倍,若是发生操作顺序逆转,先翻倍再减去100,得到的结果就大相径庭了。这里就需要一个规则,给日志编个序号,我们按日志产生的顺序给每条日志编号,然后按日志编号来重做日志,就不会发生日志重做发生混乱的情况。在实现的过程中,我们在记录日志的时候,是按日志产生的顺序依次写入磁盘的,即使是写到日志缓冲区中,也是按产生的顺序依次写到日志缓冲区,再将日志缓冲区顺序写到磁盘中。因此我们可以采用日志在日志文件中的偏移来代替这个日志编号,不仅不需要额外的磁盘开销,而且还能通过这个偏移迅速定位到这个日志,真是个神奇的想法,我们给这样的日志编号起了一个特殊的名字:lsn,这就是lsn的由来。
但我们又发现一个新的问题,虽然我们知道了所有的历史操作和它们之间的顺序关系,但不知道这些操作的影响是否已经保存到磁盘,如果简单的重做所有操作,会不会把已经做过的操作重复进行。比如购物转账转了两次钱出去?所以在每个数据块的块头记录下最后一次修改这个数据块的操作的日志编号lsn,当重做日志时,数据块加载到缓冲区中,称之为页面,若页面的header中lsn比当前重做日志的lsn小,则说明当前日志尚未被重做; 若不比当前重做日志的lsn小,即大于或等于当前重做日志的lsn,则说明当前日志已经被重做,或不需要重做;通过这种方法,可以避免日志被重复重做,从而得到正确的恢复结果。
(2)
In PostgreSQL terminology, an LSN (Log Sequence Number) is a 64-bit integer used to determine a position in WAL (Write ahead log), used to preserve data integrity. Internally in code, it is managed as XLogRecPtr, a simple 64-bit integer. An LSN is represented with two hexadecimal numbers of 8 digits each separated with "/". For example, when looking on server what is the current position of WAL, you can do something like that
select pg_current_xlog_location();
(learn from http://michael.otacoo.com/)
参考:
漫谈postgresql的日志实现机制
http://blog.csdn.net/xabc3000/article/details/7658439
Postgres 10 highlight - recovery_target_lsn
http://paquier.xyz/postgresql-2/postgres-10-recovery-target-lsn/
:: 推荐
Postgres的WAL机制
http://www.linuxso.com/sql/12200.html