Hello!
I currently use Slony for replication and want to switch to logical
replication. With Slony I was aware of the replication lag of each slave
in seconds. This info was available regardless if a slave was online or
offline.
For my application I need to know the "delay" of all replicas, wethe
Hi Michael!
Am 21.02.2020 um 21:24 schrieb Michael Lewis:
I am very interested in this discussion. We settled a table with a
single timestamp field that a script updates every minute with NOW() so
that we can check the timestamp of that table on the replica, assuming
the clocks are synced, the
Hello all!
When subscribing a slave I need to know when the initial sync is
finished. Is there some table I can query to know if the initial sync is
finished?
Thanks
Klaus
For the records - with a simple script I hacked a solution which is
purely based on the server.
1. Create a table to track the timestamp of an lsn:
CREATE TABLE lsn2date(
lsn pg_lsn PRIMARY KEY,
seen timestamp NOT NULL DEFAULT NOW()
);
CREATE ROLE replication_lag_user WITH LOGIN PASSWORD 'x
Am 26.02.2020 um 17:48 schrieb Klaus Darilion:
Hello all!
When subscribing a slave I need to know when the initial sync is
finished. Is there some table I can query to know if the initial sync is
finished?
No solution to this? At least the replication worker need to be aware if
it has
Am 2024-01-16 19:51, schrieb Jim Nasby:
On 1/11/24 6:17 PM, Antonin Bas wrote:
Hi all,
I have a use case for which I am considering using Postgres Logical
Replication, but I would like to scale up to 100 or even 200
replication slots.
I have increased max_wal_senders and max_replication_slo
Hi Saheed!
I monitor our replication this way:
1. Every 10 seconds i fetch the current LSN and write it into a table,
next with the current timestamp. Further I fetch confirmend LSNs from
the replication slots and delete old entries in lsn2data table.
calculate_logical_replication_lag.php:
Hello!
If I understand it right, the logical replication .spill files in the
pg_replslot subfolders are temporary files that need not survive server
crashes (as on postgresql restart the WAL senders will delete old spill
files, start again reading WAL and regenerate the spill files if
necessa
l
senders and 2 streaming senders to barman), the database was shut down and the
switchover happened.
I do not know for sure, but I think the walsenders to the patroni replicas,
that were using the host IP and not the VIP, were still active wenn we removed
the VIP. But it seems they have shut
