你可以看到这些问题
https://www.reddit.com/r/aws/comments/7snob5/postgresql_transaction_logs_fill_up_storage_till/
https://dba.stackexchange.com/questions/173267/aws-rds-postgres-logical-replication?rq=1
我的问题可能有点不同。当数据发生变化时,我使用https://github.com/jiamo/python-psql-replication从postgres复制到es。当有数据更改时,事务日志就可以了。但当不再有数据更改时,Transactioin日志将继续如下:
09/23-09/25现在是周末(因此不再有数据更改,事务日志继续运行)
我有一些技巧,想通过在crontab中更新一些数据来解决这个问题。但当数据更改时,事务日志似乎不会立即关闭(这需要更多的时间来验证此方法)
我现在的问题是:有谁能解释这一现象并提供更好的解决方法吗?
增加更多关于诀窍是什么的内容。
=> SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
CD/1C0005C0
(1 row)
两小时后:
=> SELECT pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
CD/41000410
当没有插入/更新/删除活动时。目前的pg_wal_lsn仍在继续增长。
pg插槽是这样的
=> select * from pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn
--------------+----------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------
wal2json_rds | wal2json | logical | 16400 | test | f | t | 11270 | | 593776 | CD/140235B8 | CD/140235B8
confirmed_flush_lsn
比pg_current_wal_lsn
小。诀窍(这里是日志)是,我使用crontab更新一个简单的行,但之后就没有数据更改了。并且确认的血迹保持在
CD/140235B8
:host:25a5743b67db time:2018-10-01 09:23:21.865489 before sleep wal_end 875955403896 hex CB/F302BC78 next_lsn 876123392024 hex CB/FD060818
host:25a5743b67db time:2018-10-01 09:23:32.087501 before sleep wal_end 875955403896 hex CB/F302BC78 next_lsn 876123392024 hex CB/FD060818
host:25a5743b67db time:2018-10-01 09:23:38.705198 future len tmp_list is 1
host:25a5743b67db time:2018-10-01 09:23:38.763092 success bulk 1
host:25a5743b67db time:2018-10-01 09:23:38.763327 queue 0 getters 1 putters 0
host:25a5743b67db time:2018-10-01 09:23:38.763503 queue begin to wait......
host:25a5743b67db time:2018-10-01 09:23:42.310556 before sleep wal_end 880803984024 hex CD/14023298 next_lsn 880803984824 hex CD/140235B8
host:25a5743b67db time:2018-10-01 09:23:52.531998 before sleep wal_end 880803984024 hex CD/14023298 next_lsn 880803984824 hex CD/140235B8
我的诀窍是在没有其他数据更改时增加
confirmed_flush_lsn
(通过更新行的status列)。但它似乎增加了值,但并没有使RDS删除一些事务日志。--------更新------------
我改变了改变两行而不是一行的技巧(意味着有更多的数据改变),这次事务日志可以减少,但仍然不能像这个png那样减少太多。在周末,我的技巧可以减少事务日志的大小。但不像正常的一天,当有更多的数据变化和大小可以减少到0。
最佳答案
在CDC模式下,AWS的数据迁移服务(Data Migration Service,DMS)创建一个复制槽并订阅它,就像您正在做的一样。它包括一个选项,用于发送常规的伪查询,以确保复制插槽位置得到提升。我不清楚它是如何实现的,但我相信它会指引你正确的方向。在DMS release notes中搜索“WAL heartbeat”。