​译者简介

晏杰宏，任职于上海新炬网络信息技术股份有限公司，Oracle DBA。负责数据库、中间件、大数据等基础软件建设、优化和业务保障工作。具有10年以上电信与银行企业一线/二线数据库运维管理经验。目前专注研究云计算、开源软件和国产化数据库等领域技术研究。

校对者简介

崔鹏,任职于海能达通信股份有限公司,数据库开发高级工程师,致力于postgresql数据库在专网通信领域、公共安全领域的应用与推广。

背景

PostgreSQL中的逻辑复制是一种发布-订阅模型，订阅服务器节点可以订阅发布服务器并实时接收来自发布服务器的逻辑更改。创建订阅时，将在发布服务器节点中生成walsender进程。walsender进程负责逐个读取WAL并重新组合属于每个事务的更改。walsender进程将更改存储在内存中，如果更改超过内存限制，则将其刷新到本地文件。在事务提交时，它对相应的更改进行解码，并将它们发送到订阅服务器，在那里以增量方式应用这些更改。解码后的WAL的传输受网络带宽的限制，用户在应用WAL和赶上发布服务器时会出现延迟。应用侧的这种延迟称为应用延迟。

处理大型事务通常会导致严重的应用延迟，因为如上所述，只有在提交时，所有更改才会同时发送到下游。对于大型事务，进行网络传输的时间可能很长，这将导致应用延迟。

正在进行的事务的逻辑复制

在PostgreSQL 14中，我们将允许正在进行的事务流传输，而不是将它们溢出到本地文件中。在应用方面，我们仅接收流式更改并将其写入文件中。在提交时，更改将在本地重播，而不必等待大量数据通过网络中继。这样做有两个主要优点:

1. 提交时无需通过网络发送大数据。

2. 如果在不相关的表（未发布的表）上发生了一些重大更改，则可以将这些更改尽早丢弃，而不必将其溢出到本地文件中。

在postgresql13中，添加了一个新的配置参数logical_decoding_work_mem，该参数控制分配给walsender进程的内存量，以便在将更改溢出到磁盘之前将更改存储在内存中。相同的参数规定了何时将更改发送到下游。基本上，只要Walsender进程中的内存中更改超过此大小，我们就会根据其内存中更改大小选择最大的事务，并流式传输所有更改。重复此过程，直到达到内存限制。

如何解码正在进行的事务

为了使用test_decoding插件解码正在运行的事务的更改，请在pg_logical_slot_get_changes中使用新选项'stream-changes'。

例如

logical_decoding_work_mem=”64kB”;
postgres[89179]=# CREATE TABLE stream_test(data text);
CREATE TABLE
postgres[89179]=# BEGIN;
BEGIN
postgres[89179]=#* INSERT INTO stream_test SELECT repeat('a', 2000) || g.i FROM generate_series(1, 35) g(i);
INSERT 0 35
postgres[89179]=#* SELECT data FROM pg_logical_slot_get_changes('regression_slot', NULL,NULL, 'stream-changes', '1');
data
--------------------------------------------------
BEGIN 553
COMMIT 553
opening a streamed block for transaction TXN 554
streaming change for TXN 554
streaming change for TXN 554
streaming change for TXN 554
streaming change for TXN 554
streaming change for TXN 554
streaming change for TXN 554
…..
closing a streamed block for transaction TXN 554
(35 rows)

为了在逻辑复制设置中启用正在进行的事务的流传输，我们需要在创建预订时传递一个新选项（streaming = on），例如

CREATE SUBSCRIPTION tap_sub CONNECTION '$publisher_connstr application_name=$appname' PUBLICATION tap_pub WITH (streaming = on)

性能测试

[publisher configurations]:
wal_level = logical
synchronous_standby_names = '*' [this is set so that commit will wait for response from downstream]
logical_decoding_work_mem=10MB
​
[publisher setup]:
CREATE TABLE publish_table(a int ,b text);
CREATE TABLE non_publish_table(a int ,b text);
CREATE PUBLICATION test_pub FOR TABLE publish_table;
​
[subscription setup]
CREATE TABLE publish_table(a int ,b text);
CREATE SUBSCRIPTION test_sub CONNECTION 'host=127.0.0.1 port=5432 dbname=postgres' PUBLICATION test_pub;
​
[performance test]:
Execute a large transaction on the publisher and measure the total commit time (local commit + subscriber apply + ack from the subscriber)
The transaction operates on published as well as non-published tables
​
BEGIN;
INSERT INTO non_publish_table SELECT i, REPEAT('x', 10) FROM generate_series(1,5000000) AS i;
INSERT INTO publish_table SELECT i, REPEAT('x', 10) FROM generate_series(1,1000000) AS i;
COMMIT;
​
Time taken for COMMIT: 5,7087.004 ms
​
Enable the streaming and recheck the performance.
ALTER SUBSCRIPTION test_sub SET(STREAMING = ON)
Time taken for COMMIT: 2,3967.789 ms

结论：

如果启用正在进行的事务流，我们可以注意到提交时间大大减少。这主要是由于：

1. 无关的更改不会溢出到磁盘上，从而降低了I / O成本。

2. 在等待发送方处理事务的同时，我们不等待事务提交，而是连续将更新发送给接收方。

进一步的改进范围

目前在应用端，我们将正在进行的事务的更改刷新到订阅服务器端文件中，只有在提交时，我们才读取并应用这些更改。这样做的原因是，正在进行的事务的更改可以交错进行，在订阅者端，我们需要将所有更改应用于单个订户端事务下的事务。因此，为了进一步减少应用延迟，我们可以启动订阅端工作线程并立即应用更改，而不是将更改刷新到文件中。但是仍然有许多问题需要解决，所以还不清楚这个功能何时可用。

PostgreSQL提交

此功能已提交给PostgreSQL，并将在PostgreSQL版本14中可用。

1. 在ReorderBuffer中实现流模式

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=7259736a6e5b7c7588fff9578370736a6648acbb

2. 将对流的支持添加到内置逻辑复制中

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=464824323e57dc4b397e8b05854d779908b55304

原文链接：https://www.enterprisedb.com/blog/logical-decoding-large-progress-transactions-postgresql