PostgreSQL的clog—从事务回滚速度谈起

如果是之前学习别的数据库的人，看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。那么写入的时候，顺序如下：

1. 设置p2 的t2 t3为子提交，之后设置p3的t4位子提交

2. 设置t1为子提交，之后设置t为已提交，之后设置t1为已提交

3. 设置 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这一类问题，在未来必然会得到更好的处理。

往期精选

---

作者：刘伟，云和恩墨软件开发部研究院研究员；前微博DBA，主要研究方向为开源数据库，分布式数据库，擅长自动化运维以及数据库内核研究。

编辑：尹文敏

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂