PostgreSQL 14中两阶段提交的逻辑解码正文-电子发烧友网

Fujitsu OSS团队和PostgreSQL开源社区合作在PG14中添加了在逻辑复制中对两阶段提交进行解密的功能。下面看看这项功能是什么？

背景

两阶段提交是事务以两阶段进行提交的一种机制。通常在分布式数据库中用于保证一致性。事务的两阶段是PREPARE阶段和COMMIT／ROLLBACK阶段。PG中两阶段提交的命令是：

PREPARE TRANSACTION

COMMIT PREPARED

ROLLBACK PREPARED

PG在8．0版本已经支持了两阶段提交，10．0版本支持逻辑复制。但是逻辑复制中一直都不支持两阶段提交。单实例中已经支持了PREPARE TRANSACTION、COMMIT PREPARED和ROLLBACK PREPARED命令，但是当这些命令需要逻辑复制到备机时，他们不再保持原始含义。PREPARE TRANSACTION命令被视为NOP，而根本没有解码。COMMIT PREPARED命令被视为COMMIT，ROLLBACK PREPARED命令被视为ABORT。

什么是两阶段提交

两阶段提交是一种原子提交协议，有助于维护分布式数据库之间的一致性。提供数据库内原子性的普通提交不足以为跨数据库的事务提供一致性。为说明这个问题，我们举一个例子：

1） John在A银行有300＄

2） Mark在B银行有100＄

3） John想给Mark转100＄

事务进行过程中，需要从A银行提取100＄到银行B。事务结束的时候，应该都有200＄．如果在转账的过程中，任何时候任何一笔交易失败，那么账户状态应该恢复到转账开始前的状态。事务可能因各种原因而失败。如果在事务提交之前发生任何中断，则该事务会回滚。在我们的示例中，如果John的账户中扣除金额时发生中断，那么中断口John的账户不应该减少。这就是简单的提交如何保持数据库内的一致性。

但是我们考虑这样一种情况，即从John账户中扣除100＄的事务在一次提交时成功，但向Mark在B银行的账户中添加100＄的事务失败而被回滚。然后此操作结束后，虽然John账户已扣款，但Mark将不会收到该金额。100＄消失了。在处理分布式事务时，简单的提交有可能失败。

分布式事务的分步执行

对于两阶段提交，其中一个数据库充当分布式事务的协调器。

阶段1

一个数据库开始应用事务，然后做Prepare。它以prepare消息形式发送prepared事务到其它数据库。第2个数据库获取到Prepare消息，然后prepare该事务。Prepare涉及事务中的修改，但不提交。这些脏数据写到磁盘以持久化。一旦所有数据库都prepare了事务，并且有关该事务的所有信息都存储到磁盘上，prepare阶段就完成了。

阶段2

接下来，仲裁器启动提交阶段。如果第2个数据库由于某种原因未能准备事务，则仲裁器启动回滚阶段。因此根据prepare是否成功，事务要么提交，要么回滚。在最后提交阶段发生中断是可以恢复的，因为所需的prepare事务已经写入磁盘并可以重新应用。

两阶段提交与单实例数据库并不相关，但若数据复制跨多个数据库实例时，就相关了。

逻辑复制中支持两阶段提交非常重要。

功能概述

在PG14版本前，逻辑复制事务仅在事务提交后才被解码和复制。这是为了避免复制事务可能最终被中止。

提交时解码事务

PG14的逻辑复制支持PREPARE TRANSACTION、COMMIT PREPARED和ROOLBACK PREPARED命令。当PREPARE TRANSACTION命令解码时，事务被解码并复制。PREPARE TRANSACTION就像WAL SENDER中COMMIT一样启动事务重放和解码。