学习分布式事务一致性？这几个重点别忘划

头像
Greenplum
    阅读 6 分钟
    了解更多Greenplum技术干货，欢迎访问Greenplum中文社区网站

    ​新年假期后的第一周来啦！不知大家都是如何度过新年的呢？

    在之前的文章《不惧宕机，数据库高可用理论与实践》中，为大家介绍了数据库系统的高可用理论知识，以及Greenplum是如何实现高可用，为企业的数据保驾护航的。

    今天我们将在上篇文章的基础上，补充介绍Greenplum事务一致性的几个重点，它们也是Greenplum可以高可用的重要前提和保证。本文将就分布式事务日志在时间线上的顺序，以及事务的提交和可见在代码层面的细节逐一分析讲解。

    分布式事务日志

    image

    我们以 CREATE TABLE t1(i int); 为例介绍关键事务日志的时间线。随后讲解事务在各个阶段发生故障时，Greenplum怎样保证数据的一致性。

    1. QD/QE进程更新数据库对象，插入表格。
    2. QD进程通知segments执行PREPARE TRANSACTION，并等待所有primary节点上的QE返回成功。
    3. primary上的QE在本地执行完PREPARE TRANSACTION后，将WAL刷盘，并唤醒walsender进程，并将WAL同步到mirror本地。primary上的QE成功地将WAL同步后，返回结果给QD，至此该primary准备就绪。
    4. 所有的segments准备就绪后，QD在本地写入DISTRIBUTED_COMMIT日志并刷盘，然后唤醒walsender进程，并等待将日志同步至standby。
    5. QD进程发起两阶段提交的COMMIT PREPARED。
    6. primary上的QE进程执行COMMIT PREPARED。QE在本地写入COMMIT_PREPARED日志并刷盘，唤醒walsender进程后，等待将日志同步至mirror。
    7. primary上的QE进程等待日志成功同步至mirror后，将结果返回给QD。
    8. QD等待所有的segments都成功提交后，写入DISTRIBUTED_FORGET。此记录并不需要刷盘，没有它数据库也能工作。它的作用仅仅是优化了数据库恢复过程，告诉恢复进程“这个分布式事务已经成功提交(包括segments），忽略掉它，不要再尝试提交了”。

    真实的WAL日志

    master节点上的事务日志

    rmgr: Heap      len (rec/tot):   54/  1378, tx:      986, lsn: 0/7407A748, prev 0/74075578, desc: INSERT off 13 flags 0x00, blkref #0: rel 1663/57434/7142 blk 0 FPW
rmgr: Btree     len (rec/tot):   53/   353, tx:      986, lsn: 0/7407ACB0, prev 0/7407A748, desc: INSERT_LEAF off 13; page 1, blkref #0: rel 1663/57434/6103 blk 1 FPW
rmgr: Heap      len (rec/tot):  215/   215, tx:      986, lsn: 0/7407AE18, prev 0/7407ACB0, desc: INSERT+INIT off 1 flags 0x00, blkref #0: rel 1663/57434/6052 blk 0
rmgr: Btree     len (rec/tot):   94/  94, tx:      986, lsn: 0/7407AEF0, prev 0/7407AE18, desc: NEWROOT lev 0, blkref #0: rel 1663/57434/6054 blk 1, blkref #2: rel 1663/57434/6054 blk 0
rmgr: Btree     len (rec/tot):   72/  72, tx:      986, lsn: 0/7407AF50, prev 0/7407AEF0, desc: INSERT_LEAF off 1; add length 24 item at offset 1 in page 1, blkref #0: rel 1663/57434/6054 blk 1
rmgr: Heap2     len (rec/tot):   70/  70, tx:      986, lsn: 0/7407AF98, prev 0/7407AF50, desc: CLEAN remxid 968, blkref #0: rel 1663/57434/1249 blk 17
rmgr: Standby   len (rec/tot):   42/  42, tx:      986, lsn: 0/7407AFE0, prev 0/7407AF98, desc: LOCK xid 986 db 57434 rel 57435
rmgr: Transaction len (rec/tot):  469/   469, tx:      986, lsn: 0/7407B010, prev 0/7407AFE0, desc: DISTRIBUTED_COMMIT distributed commit 2021-02-22 17:30:36.383408 UTC gxid = 8730
rmgr: Transaction len (rec/tot):   34/  34, tx:      986, lsn: 0/7407B1E8, prev 0/7407B010, desc: DISTRIBUTED_FORGET distributed forget gxid = 8730

    segment上的事务日志

    rmgr: Heap      len (rec/tot):   54/  1378, tx:      885, lsn: 0/881D8998, prev 0/881D3758, desc: INSERT off 13 flags 0x00, blkref #0: rel 1663/57434/7142 blk 0 FPW
rmgr: Btree     len (rec/tot):   53/   353, tx:      885, lsn: 0/881D8F00, prev 0/881D8998, desc: INSERT_LEAF off 13; page 1, blkref #0: rel 1663/57434/6103 blk 1 FPW
rmgr: Standby   len (rec/tot):   42/  42, tx:      885, lsn: 0/881D9068, prev 0/881D8F00, desc: LOCK xid 885 db 57434 rel 57435
rmgr: Transaction len (rec/tot):   1005/  1005, tx:      885, lsn: 0/881D9098, prev 0/881D9068, desc: PREPARE at = 2021-02-22 17:30:36.373860 UTC; gid = 8730
rmgr: Transaction len (rec/tot):  465/   465, tx:        0, lsn: 0/881D9488, prev 0/881D9098, desc: COMMIT_PREPARED 885: 2021-02-22 17:30:36.386186 UTC; inval msgs: catcache 80 catcache 79 catcache 80 catcache 79 catcache 53 catcache 52 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 34 snapshot 2608 relcache 57435

    故障分析

    事务开始后，完成DISTRIBUTED_COMMIT写入之前，一旦master（严格来说是Query Dispatch, i.e. QD进程）或任一参与事务的primary（Query Execute, i.e. QE进程）发生错误/故障，事务都会被回滚。如果mirror发生故障，致使replication发生中断，primary上的FTS handler会报告给FTS probe进程。紧接着，FTS服务会请求primary设置synchronous_standby_names为空值，primary不再将WAL同步到它所对应的mirror上，并唤醒等待同步WAL的backend进程。

    只要图中的步骤3完成（master节点依旧存活），不管segment节点是否临时掉电，分布式事务都最终完成。因为分布式提交已经持久化地记录在master节点上，只要master节点还活着，它都可以去尝试请求segment提交已经处于prepared状态的事务。现实情况下，处于prepared状态的事务仍有极小的可能无法成功提交事务，一般是数据库BUG或磁盘故障。除非primary和mirror同时出现故障，segment上的事务都能成功提交。

    如果QD进程在图中步骤3完成后，master节点突然掉电，那么这个分布式事务是否可以最终提交？取决于DBA等待恢复master，还是将standby提升为新的master提交服务。如果是前者，那么这个事务依旧被认为是分布式提交了，DTX recovery进程会尝试提交已经就绪的事务。如果DBA选择提升standby，那么这个事务的分布式提交日志在standby上丢失，事务会被取消，并且是永久性的，不管原来的master节点之后怎样。

    如果primary在图中步骤3完成时，突然挂掉，FTS probe会将它对应的mirror提升为新的primary，然后再发起新的请求来完成segment本地事务提交。

    事务提交与可见

    事务的WAL记录（COMMIT/COMMIT_PREPARED）决定事务是否被提交并最终可见。写入WAL记录COMMIT/COMMIT_PREPARED并不意味着事务瞬间对其他事务可见。backend进程将WAL刷盘后，保证事务在掉电重启后依旧可以完成并最终可见，但在事务可见之前，backend进程还需要更新内存中的数据结构，使得事务在下一次事务快照（Snapshot）可见。

    首先backend计算事务及子事务的最新事务ID，并将用来更新ShmemVariableCache->latestCompletedXid。

    然后，backend写入（并刷盘）WAL记录COMMIT_PREPARED和提交日志（commit log）。在此之后，由于该backend的PGPROC并没有更新，事务对其他进程依旧不可见。

    接着，backend进程以互斥模式取得ProcArrayLock后，更新PGPROC和ShmemVariableCache->latestCompletedXid，并从procArray删除PGPROC，最后释放锁ProcArrayLock。如果此时有另外的backend进程调用GetSnapshotData()获取事务快照，它被会阻塞在拿锁操作上。

    最后，其他backend继续执行GetSnapshotData()，这个时候，刚提交的事务对其他backend进程可见了。

    如果primary在提交与可见之间发生故障，执行恢复操作后，事务后依旧可见。这是因为共享内存被重置，重做事务日志后，事务会完成并可见。

    FinishPreparedTransaction()
{
 ...
 /* compute latestXid among all children */
 latestXid = TransactionIdLatest(xid, hdr->nsubxacts, children);
 if (isCommit)
 RecordTransactionCommitPrepared(xid,
 hdr->nsubxacts, children,
 hdr->ncommitrels, commitrels,
 hdr->ncommitdbs, commitdbs,
 hdr->ninvalmsgs, invalmsgs,
 hdr->initfileinval, gid);
 else
 RecordTransactionAbortPrepared(xid,
 hdr->nsubxacts, children,
 hdr->nabortrels, abortrels,
 hdr->nabortdbs, abortdbs,
 gid);
 ProcArrayRemove(proc, latestXid);
 gxact->valid = false;
…
}
​
​
ProcArrayRemove(PGPROC *proc, TransactionId latestXid)
{
 ProcArrayStruct *arrayP = procArray;
 int                   index;
​
 LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE);
​
 if (TransactionIdIsValid(latestXid))
 {
 Assert(TransactionIdIsValid(allPgXact[proc->pgprocno].xid));
​
 /* Advance global latestCompletedXid while holding the lock */
 if (TransactionIdPrecedes(ShmemVariableCache->latestCompletedXid,
 latestXid))
 ShmemVariableCache->latestCompletedXid = latestXid;
 }
 // REMOVE PGPROC from procArray
…
}
​
Snapshot
GetSnapshotData(Snapshot snapshot, DtxContext distributedTransactionContext)
{
...
 /*
 * It is sufficient to get shared lock on ProcArrayLock, even if we are
 * going to set MyPgXact->xmin.
 */
 LWLockAcquire(ProcArrayLock, LW_SHARED);
​
 /* xmax is always latestCompletedXid + 1 */
 xmax = ShmemVariableCache->latestCompletedXid;
 Assert(TransactionIdIsNormal(xmax));
 TransactionIdAdvance(xmax);
​
 /* initialize xmin calculation with xmax */
 globalxmin = xmin = xmax;
…
 for (index = 0; index < numProcs; index++)
 {
...
 xid = UINT32_ACCESS_ONCE(pgxact->xid);
 /* Add XID to snapshot. */
 snapshot->xip[count++] = xid;
…
 }
 LWLockRelease(ProcArrayLock);
...
}

    本文对分布式事务中几个关键日志点进行了介绍和简单分析，包括它们的时间线。通过这些约束，主节点在任意时刻发生故障，Greenplum都可以达到事务一致性。在主节点发生故障时，数据库系统都可以安全地将备节点提升为新的主节点，从而达到高可用的目标。

    image

    greenplum分布式事务分享
    Greenplum
    153 声望66 粉丝

    Greenplum 是全球领先的开源、多云大数据分析平台，被广泛运用于大规模商业智能和分析中，具有极高的稳定性。

    « 上一篇
    Greenplum恢复系统知多少
    下一篇 »
    【课程合集】深入浅出Greenplum内核，错过的课程都补回来

    引用和评论

    推荐阅读
    头像
    基于Greenplum构建下一代数据分析平台

    Greenplum阅读 2.3k评论 1

    头像
    事务

    小新赞 1阅读 181

    头像
    如何轻松快速搭建一个简单的、高性能的电商系统？秒杀抢购和订单架构的设计与实现

    gvison阅读 378

    头像
    seata分布式事务解决方案 - AT 模式

    无聊的企鹅阅读 250

    头像
    Seata的AT模式的执行流程

    剣藤犬个阅读 248

    头像
    分布式事务与Seata

    玉喵阅读 221

    头像
    正式开源：从 Greenplum 到 Cloudberry 迁移工具 cbcopy 发布

    酷克数据HashData阅读 218

    0 条评论
    得票最新