Postgresql逻辑复制初始槽快照太大
Postgresql逻辑复制初始槽快照太大
提问于 2020-03-19 15:14:21
我试图用逻辑复制将一些数据从一个数据库复制到另一个数据库。
但它却陷入了追赶状态。当我查看日志时，initial slot snapshot too large，我不确定确切的含义？
我有点卡住了，不知道该去哪看。令我害怕的是，如果我看一下滞后，wal就会不断增加。
SELECT pid, usename, application_name, state
, pg_current_wal_lsn() AS current_lsn
, sent_lsn
, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), sent_lsn)) AS sent_diff
, write_lsn
, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), write_lsn)) AS write_diff
, replay_lsn
, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS replay_diff
, write_lag, flush_lag, replay_lag
FROM pg_stat_replication
ORDER BY application_name, pid;
-[ RECORD 1 ]----+----------------
pid | 23031
usename | ...
application_name | ...
state | catchup
current_lsn | 36/1F6562B0
sent_lsn | E/14669F88
sent_diff | 160 GB
write_lsn | E/4B6E1CA8
write_diff | 159 GB
replay_lsn | E/4B6E1CA8
replay_diff | 159 GB
write_lag |
flush_lag |
replay_lag | 回答 1
Database Administration用户
发布于 2023-05-19 22:33:06
逻辑是普通快照的反义词。的快照，因为它们在xmin/xmax之间存储提交的xact列表，而不是在运行中的xact列表。
列表的最大大小是基于最大_连接。因此，正如洛伦兹所说，增加max_connections可能会有所帮助。但是也值得检查一个旧的或长期运行的/空闲的事务，因为如果全局xmin地平线进一步后退，倒逻辑的rep快照可能会膨胀。
最后，现有的插槽也将阻止用于快照的xmin。GetOldestSafeDecodingTransactionId()函数确定用于构建逻辑快照的xmin。这意味着，如果您同时运行一批这样的程序，那么稍后启动的程序更有可能失败。最早的插槽会把你的xmin挂起来。延迟启动需要构建包含最早时隙之后提交的每个xid的快照。视图中的xmin列pg_replication_slots可能有助于确定这是否导致了问题。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/262294
复制相关文章
相似问题
腾讯云开发者
