Re: wal recycling problem
| От | Fabrice Chapuis |
|---|---|
| Тема | Re: wal recycling problem |
| Дата | |
| Msg-id | CAA5-nLB5axGwwj6ft6G5tHxKqEC932M5k-4Ytb2W1iQziqmuLQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: wal recycling problem (Christoph Moench-Tegeder <cmt@burggraben.net>) |
| Ответы |
Re: wal recycling problem
|
| Список | pgsql-hackers |
Yes, barman replication can keep up with primary, wals segments size are under max_wal_size (24Gb in our configuration)
Here is pg_replication_slots view:
barman_ge physical f t 39409 1EE2/49000000 reserved f
barman_be physical f t 39434 1EE2/3D000000 reserved f
on the other hand there are 2 slots for logical replication which display status extended. I don't understand why given that the confirmed_flush_lsn field that is up to date. The restart_lsn remains frozen, for what reason?
pgoutput │ logical │ 2667915 │ db019a00 │ f │ t │ 1880162 │ │ 68512101 │ 1ECA/37C3F1B8 │ 1EE2/4D6BDCF8 │ extended │ │ f │
pgoutput │ logical │ 2668584 │ db038a00 │ f │ t │ 363230 │ │ 68512101 │ 1ECA/37C3F1B8 │ 1EE2/4D6BDCF8 │ extended │ │ f │
Regards
Fabrice
On Thu, Sep 28, 2023 at 7:59 PM Christoph Moench-Tegeder <cmt@burggraben.net> wrote:
## Fabrice Chapuis (fabrice636861@gmail.com):
> We have a cluster of 2 members (1 primary and 1 standby) with Postgres
> version 14.9 and 2 barman server, slots are only configured for barman,
> barman is version 3.7.
The obvious question here is: can both of those barmans keep up with
your database, or are you seeing WAL retention due to exactly these
replication slots? (Check pg_replication_slots).
Regards,
Christoph
--
Spare Space
В списке pgsql-hackers по дате отправления: