digoal
2023-01-10
PostgreSQL , PolarDB , 逻辑复制 , 逻辑订阅 , logical_decoding_work_mem , 溢出 , 并行回放
对于大事务, PostgreSQL 逻辑订阅的流程是这样的, 发布端将解析后的数据分批发送给订阅端(一个chunk最多不超过logical_decoding_work_mem), 订阅端接收到chunk数据并写入对应临时文件, 当收到事务commit消息后, 在订阅端开始读取这些临时文件进行回放. 大事务的逻辑回放延迟会比较高.
PostgreSQL 16改进了stream协议, 下游节点支持并行回放, 由leader进程负责接收, 并通过shared memory共享给多个apply worker process, 每个apply worker process负责一个chunk, 并行回放. 如果leader分配超时, 则接收并写临时文件("partial serialize" mode), 但是回放时依旧是多个apply worker process并行回放(只不过是需要读临时文件.
Perform apply of large transactions by parallel workers.
author Amit Kapila <akapila@postgresql.org>
Mon, 9 Jan 2023 01:30:39 +0000 (07:00 +0530)
committer Amit Kapila <akapila@postgresql.org>
Mon, 9 Jan 2023 02:22:45 +0000 (07:52 +0530)
commit 216a784829c2c5f03ab0c43e009126cbb819e9b2
tree 9051220c20b086f981c941397b775b9c83023d43 tree
parent 5687e7810f1dd32ac1960e67b608c441d87bc229 commit | diff
Perform apply of large transactions by parallel workers.
Currently, for large transactions, the publisher sends the data in
multiple streams (changes divided into chunks depending upon
logical_decoding_work_mem), and then on the subscriber-side, the apply
worker writes the changes into temporary files and once it receives the
commit, it reads from those files and applies the entire transaction. To
improve the performance of such transactions, we can instead allow them to
be applied via parallel workers.
In this approach, we assign a new parallel apply worker (if available) as
soon as the xact's first stream is received and the leader apply worker
will send changes to this new worker via shared memory. The parallel apply
worker will directly apply the change instead of writing it to temporary
files. However, if the leader apply worker times out while attempting to
send a message to the parallel apply worker, it will switch to
"partial serialize" mode - in this mode, the leader serializes all
remaining changes to a file and notifies the parallel apply workers to
read and apply them at the end of the transaction. We use a non-blocking
way to send the messages from the leader apply worker to the parallel
apply to avoid deadlocks. We keep this parallel apply assigned till the
transaction commit is received and also wait for the worker to finish at
commit. This preserves commit ordering and avoid writing to and reading
from files in most cases. We still need to spill if there is no worker
available.
This patch also extends the SUBSCRIPTION 'streaming' parameter so that the
user can control whether to apply the streaming transaction in a parallel
apply worker or spill the change to disk. The user can set the streaming
parameter to 'on/off', or 'parallel'. The parameter value 'parallel' means
the streaming will be applied via a parallel apply worker, if available.
The parameter value 'on' means the streaming transaction will be spilled
to disk. The default value is 'off' (same as current behaviour).
In addition, the patch extends the logical replication STREAM_ABORT
message so that abort_lsn and abort_time can also be sent which can be
used to update the replication origin in parallel apply worker when the
streaming transaction is aborted. Because this message extension is needed
to support parallel streaming, parallel streaming is not supported for
publications on servers < PG16.
Author: Hou Zhijie, Wang wei, Amit Kapila with design inputs from Sawada Masahiko
Reviewed-by: Sawada Masahiko, Peter Smith, Dilip Kumar, Shi yu, Kuroda Hayato, Shveta Mallik
Discussion: https://postgr.es/m/CAA4eK1+wyN6zpaHUkCLorEWNx75MG0xhMwcFhvjqm2KURZEAGw@mail.gmail.com
