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一样启动事务重放和解码。
prepare时解码事务
我们还定义了新的插件回调,允许逻辑解码插件支持两阶段提交。
回调函数 |
描述 |
filter_prepare_cb |
允许插件根据PREPARE TRANSACTION命令中使用的GID过滤Prepare时不需要解码的事务 |
begin_prepare_cb |
Prepare事务的开始 |
prepare_cb |
当PREPARE TRANSACTION命令被解码时调用 |
commit_prepared_cb |
当COMMIT PREPARED命令解码时调用 |
rollback_prepared_cb |
当ROLLBACK PREPARED命令解码时调用 |
详细信息请参考:
https://github.com/postgres/postgres/commit/0aa8a01d04c8fe200b7a106878eebc3d0af9105c
插件修改
test_decoding
该插件是一个逻辑解码输出插件,作为一个示例帮助用户开发自己的逻辑解码插件。test_decoding通过逻辑解码机制接收WAL,并将其解码为所执行操作的文本表示。
它被修改为能够在prepare时使用新的两阶段回调函数和解码事务
APIs的修改
pg_create_logical_replication_slot()
该API添加了新的选项指定slot是否支持两阶段提交。输出插件可以使用带有两阶段选项的复制槽以支持两阶段提交。
pg_create_logical_replication_slot(slot_name name, plugin name [, temporary boolean, two_phase boolean ] )
详细请参考:
https://github.com/postgres/postgres/commit/19890a064ebf53dedcefed0d8339ed3d449b06e6
案例
看下怎么检测两阶段提交的事务解码输出:
1) 创建一个复制槽
使用test_decoding作为输出插件,传入true,这样slot支持两阶段提交解码。
postgres=# SELECT * FROM pg_create_logical_replication_slot('regression_slot', 'test_decoding', false, true); slot_name | lsn -----------------+----------- regression_slot | 0/16B1970 (1 row)
2) 创建一个表
postgres=# CREATE TABLE data(id serial primary key, data text); CREATE TABLE
3) 检测prepare事务和commit事务的解码输出内容
postgres=# BEGIN; postgres=*# INSERT INTO data(data) VALUES('5'); postgres=*# PREPARE TRANSACTION 'test_prepared1'; postgres=# SELECT * FROM pg_logical_slot_get_changes('regression_slot', NULL, NULL); lsn | xid | data -----------+-----+--------------------------------------------------------- 0/1689DC0 | 529 | BEGIN 529 0/1689DC0 | 529 | table public.data: INSERT: id[integer]:3 data[text]:'5' 0/1689FC0 | 529 | PREPARE TRANSACTION 'test_prepared1', txid 529 (3 rows) postgres=# COMMIT PREPARED 'test_prepared1'; postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NULL); lsn | xid | data -----------+-----+-------------------------------------------- 0/168A060 | 529 | COMMIT PREPARED 'test_prepared1', txid 529 (4 rows) postgres=# select * from data; id | data ----+------ 1 | 5 (1 row)
未来
PG14对此功能的更改,有了解码器端的基础架构,允许在prepare时解码两阶段提交。我们还修改了test_decoding插件以利用此基础架构。
下一步就是把对两阶段的支持实现到PG内部最大的逻辑解码插件--pgoutput插件中。这个插件支持逻辑复制的PUBLISHER/SUBSCRIBER 模式。他是逻辑复制中使用最广泛的插件。富士通OSS团队正在和开源社区合作,以在PG15中添加此功能。
对于分布式数据库中的两阶段事务,PG也需要支持:备机通知主机PREPARE失败了,发起回滚。这种反馈机制在PG中不支持,是未来改进的方向之一。
原文
https://www.postgresql.fastware.com/blog/logical-decoding-of-two-phase-commits