当前位置: 首页 >> 技术文章 >> PostgreSQL的clog—从事务回滚速度谈起
PostgreSQL的clog—从事务回滚速度谈起
发布时间:2019-08-16 发布人:刘伟 871


如果是之前学习别的数据库的人,看PostgreSQL会感觉到有句话非常奇怪:“PostgreSQL的回滚是立即完成的,不会受到事务大小本身的影响”。

 奇怪在哪里呢?比方我曾经遇到过一次MySQL的故障,一个开发给生产数据库导入数据,用的是Python脚本,但是,他没有注意一个事情,Python的MySQLdb默认情况下,是设置autocommit为0的,于是这哥们导数据(这里说的导入,不是普通那种load data,而是带有业务操作的SQL语句,所以需要脚本操作)脚本跑了一天之后,整个数据库的状况就变得极为糟糕了:他导入所用的,是一个业务的核心表,一堆业务操作都需要操作这个表,但随着这个导入动作跑了一天,占掉了大量的行锁(几百万行锁)之后,整个业务系统的对外服务都会处于一个无法求到锁的状况了(还掺和着MySQL间隙锁的坑坑洼洼),业务服务停摆,于是,作为DBA来说,最终的决策,只有杀掉这个”大”事务了。一个kill命令过去之后,我们当时俩DBA开始慢慢数—小蚂蚁慢慢爬——碰到—颗大豆芽——碰到两颗大豆芽——

最终在将近三个小时的rollback之后,这个事务完成回滚,业务系统恢复。

所以看到PostgreSQL的这个描述之后,我第一时间的反应是,why?how?what?

于是就有了这一篇文章,我从PG的事务可见性判断讲起,整理一下PG核心文件clog的机理与作用。

另注:从pg 10以后,clog改名为xact,主要原因,是很多人习惯性地使用*log删除日志文件,总是会不小心删除掉原先的xlog与clog文件,导致数据库不可用,所以分别改名为wal与xact,后文依然以clog为讨论单词,需要注意。

 
clog简介


第一个问题,什么是clog?或者换个说法,PG到底有哪些日志,它们分别是干啥的?

除了理所当前的各路文本记录(比方数据库的运行报错日志之类),PG的二进制类日志文件主要有两个,一个就是对应传统数据库理论的redo日志,理论上,所有数据的修改操作都会被记录到这个日志,在事务提交的时候确保操作都记录到磁盘中,这样讲即便发生宕机,数据库也能以不丢数据的形态重新复活。

但是,各个数据库在这个点上都有不同的实现,比方MySQL会有一个binlog用于跨存储引擎的主从同步,而在PG中,主从同步已经通过redo日志(PG术语为XLOG)同步的情况下,为了处理没有undo带来的一系列问题,其中可见性判断这个功能,就是交给clog日志文件解决的。

Clog中记录了每一个事务相关的xid(记得之前曾吐槽过这个玩意的大小问题带来的freeze问题)以及xid对应的事务的提交状态。提交状态包括以下一些:执行中,已提交,已中断,已提交的子事务。看到这里,就可以明白,只要事务提交的时候,设置状态为已提交,而事务回滚的时候,设置状态为已中断,就可以达到目的,的确避免了操作数百万行的事务突然要回滚时候的巨大代价。

但我看到这里的时候,就产生一个疑惑,这样的话,我查数据的时候,见到一行的xid之后,需要马上确认其可见性,就需要去查clog,这个查询频率势必极高而且随机性很大,这个问题该怎么解决呢?

#define CLOG_BITS_PER_XACT    2

#define CLOG_XACTS_PER_BYTE 4

#define CLOG_XACTS_PER_PAGE (BLCKSZ * CLOG_XACTS_PER_BYTE)

#define CLOG_XACT_BITMASK    ((1 << CLOG_BITS_PER_XACT) - 1)

#define TransactionIdToPage(xid)    ((xid) / (TransactionId) CLOG_XACTS_PER_PAGE)

#define TransactionIdToPgIndex(xid) ((xid) % (TransactionId) CLOG_XACTS_PER_PAGE)

#define TransactionIdToByte(xid)    (TransactionIdToPgIndex(xid) / CLOG_XACTS_PER_BYTE)

#define TransactionIdToBIndex(xid)      ((xid) % (TransactionId) CLOG_XACTS_PER_BYTE)

PG代码给了一个非常精彩的回答。

还记得之前vacuum那个里面,我大力吐槽PG对32位xid的执着,但这个32位id果真一无是处吗?看到这里才明白,还留着这么一笔思路。

一个简单的算术,每个事务标记占据2个比特位(无符号0 1 2 3对应前面提到的事务状态),也就是说,每个字节可以保存4个事务,每当PG需要确定当前事务状态的时候,就直接根据当前事务id计算得到对应的clog页位置(除每页clog之后的整数商是页数字,而余数则是在页中的具体位置)。真是把文件当hash表用的典范啊。

在32位xid的情况下,假设xid限制是20亿,每个8K的clog页存储32k事务位的情况下,clog最大也才五百来MB,这部分交给操作系统的文件缓存足以保障访问效率了。

真是一个绝妙的主意不是么?如果不考虑64位xid的情况下,clog大小完全不可控的情况的话。

还是把话题集中在clog,下面我们来探讨的是,当事务提交或者回滚的时候,其内部的运作机理又是如何呢?

以及,前文中可以看到的一个明显问题,pg这种操作的话,写入的行必然是一个”执行中事务状态”的行,这种行难道是每次查的时候,都得去找clog判断吗?如果频繁扫他几百万行,是不是会有问题?

 
clog实现内部


前面提到,clog里面会记录的是xid对应的事务状态。在PG里面,xid是一个珍贵的资源(考虑到每20亿大限的成住空坏),因此并不是每个事务都会被分配到xid。

一般来说,只有一个事务进行了数据修改(比如insert,update,delete)之类的操作,才会被分配给一个xid。

当这个事务最终提交或者回滚的时候,其最终状态就会被记录入clog。


事务提交与回滚时候的clog操作


首先来说提交。

抛开其他各种过程,每次事务提交的时候,主要的调用路径是: CommitTransaction(提交事务时候调用)-> RecordTransactionCommit(记录事务为已提交)-> TransactionIdCommitTree(同步标记事务为提交)/TransactionIdAsyncCommitTree(异步标记事务为提交,调用下一步需要提供lsn)-> TransactionIdSetTreeStatus(设置事务与子事务状态)-> TransactionIdSetPageStatus(设置单数据页内事务状态)-> TransactionIdSetPageStatusInternal(设置实际文件页)-> TransactionIdSetStatusBit(设置比特位)

其中值得拿出来讲的,主要是TransactionIdSetTreeStatus这个方法。

这里涉及到一个概念,子事务。在PG这个地方,子事务的概念主要指:事务从开始到结束,期间可以savepoint,之后rollback到savepoint而不是事务起点,在实际情况中多有应用,因此这里父事务与子事务(比如事务最终提交,但期间有回滚的情况,或者事务期间多次save point)必须尽可能原子性的方式写入,否则事务可见性就会出现问题。

在代码注释里面,对这里的写入做了一个比较直观的例子:

比如一个事务t,有子事务 t1,t2,t3,t4,其中t,t1被映射到clog页p1,t2和t3在p2,t4在页p3。那么写入的时候,顺序如下: 

设置p2 的t2 t3为子提交,之后设置p3的t4位子提交

设置t1为子提交,之后设置t为已提交,之后设置t1为已提交 

设置 t2 t3 为已提交,设置t4位已提交

对于回滚,实际上也是调用TransactionIdSetTreeStatus方法,只是上层函数是TransactionIdAbortTree,设置的标记是TRANSACTIONSTATUSABORTED,也就是记录事务为中断。语义上来说,对于事务中断,由于事务的原子性要求,中断的事务数据就是不可见的了,没啥问题。

 
数据行事务可见性的判断与clog


众所周知的是,pg新增行都会对原先的行打一个删除标记,然后写在原先行的旁边,理所当然地,每个数据行都会记录一个事务标记(当然还有数据行对应的事务id),来确保可见性,避免看到事务层面已经rollback的事务。

首先,写入的当时,事务没有结束的时候,必然是”执行中”这个状态。当事务之后提交,或者回滚的时候,pg是必然不会回头改这个标记的,否则无论提交还是回滚,都是一个代价巨大的事情。

就前文所言,pg的事务可见性,是通过行的事务id,找到clog里面对应的标记位置,然后判断的,这里非常理所当然的一个事情是,这种判断,每一行做一次就足够了,判断清楚后,修改掉这个事务标记为已提交或者是中断事务,后续读取的时候,就不需要回查clog了。

PG当然就是这么干的。

也就是说,前一个事务所有修改的数据,它没有在提交或者回滚的当时改掉所有的修改标记,而是把烂摊子丢给后来的人。

而这里还藏着一个问题:你既然修改了行的标记,那理所当然地,行所在数据块的校验和就变了,校验和变了,那块是不是就必须得传到wal缓存走流程了?即便没有涉及数据的变更?而且考虑到从库查询的时候,查数据也可以直接走从库的clog流程,这个数据块是不是必须传给从库?

那么,现在就有一个现成的面试问题了:PostgreSQL单纯的select执行,会不会产生WAL日志?

事实上,这里的事务标记带来的校验和的问题,在PG里面的处理是比较特殊的。

PostgreSQL里面,当且仅当设置了walloghints或者初始化时候,initdb启用了checksum的情况下,才会在设置标记为的时候去写WAL日志。

而且这里还不是每次设置标记位都会写。

必须得是,前一次checkpoint之后,数据块第一次被修改就是sethintbit操作的情况下,才会写整个数据块到WAL。

 
clog的一些衍生思考


实际上就清理过期数据,MySQL也是用delete+insert替代update,但在清理以及处理上,并没有搞到vacuum这么大代价,比如MySQL的purge线程的执行,一般很少需要特别关注,而PostgreSQL的vacuum虽然说是并行化,但是在单表内却是串行的,民间贡献的表内并行vacuum的补丁因为各种bug迟迟没有合并(目前来看PG12没戏了),这个事情为什么会这样呢?

因为clog毕竟只是事务可见性的标记,而不是事务的修改关联。在传统的undo类实现中,修改的数据,以及关联的事务等,都在undo按照顺序存储,purge执行的之后,直接从undo就可以找到对应的需要处理的数据块直接处理。

但是对于PG来说,由于仅仅只有事务标记,vacuum必须扫描所有的数据文件的数据块来处理这个问题,虽然pg里面,vacuum和统计信息采集合二为一(统计信息采集是传统数据库最大的全库扫描行为了),但必然需要付出的全库扫描代价却一个都不会少。

因此vacuum对超大表非常慢,极端情况下在vacuum freezen时候导致全库不可用(freezen结束前不允许执行新事务),就是有极大可能的事情了。

为了解决超大表,传统建议是使用分区表,但PostgreSQL的官方实现里面,分区表一直不太稳定,并且支持不足,因此又不得不引入pathman这个外部组件来协调处理,导致运维复杂度的进一步上升,就成了理所当然的事情。

不过目前就PostgreSQL 12来说,已经在逐渐开放存储引擎层面的接口,而社区中实现的undo版本的存储引擎,虽然因为完成度问题没有在本次release中发布,但未来可期,相信vacuum这一类问题,在未来必然会得到更好的处理。