From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | Giovanni Biscontini <biscontini(dot)g(at)es2000(dot)it>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: recovery_command has precedence over phisical slots? |
Date: | 2022-08-19 16:37:53 |
Message-ID: | 9a0bada8c474c73fa65f7a07e37c1ce9482686a5.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 2022-08-19 at 16:54 +0200, Giovanni Biscontini wrote:
> Hello everyone,
> I'm experiencing a behaviour I don't really understand if is a misconfiguration or a wanted behaviour:
> 1) I set up a primary server (a.k.a. db1) with and archive_command to a storage
> 2) I set up a replica (a.k.a. db2) that created a slot named as slot_2 and that has the recovery_command set to read archived wal on the storage.
> If I shutdown replica db2 during a pgbench I see the safe_wal_size queried from pg_replication_slots on the primary decrease to a certain amount but still in the max_slot_wal_kepp_size window: even
> if I restart the replica db2 before the slot_state changes to unreserved or lost I see that the replica gets needed wals from the storage using recovery_command but doesn't use slot on primary.
> Only if I comment the recovery command on the .conf of the replica then it uses slot.
> If this is a wanted behaviour I can't understand the need of slots on primary.
This is normal behavior and is no problem.
After the standby has caught up using "restore_command", it will connection to
the primary as defined in "primary_conninfo" and stream WAL from there.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Kohnert | 2022-08-19 18:09:51 | Re: High Availability PostgresDB on K8s |
Previous Message | Sumit Sengupta | 2022-08-19 15:51:23 | Re: High Availability PostgresDB on K8s |