From: | Johannes Truschnigg <johannes(at)truschnigg(dot)info> |
---|---|
To: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
Cc: | Pgsql-admin <pgsql-admin(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Postgresql 9.5: Streaming Replication: Secondaries Fail To Start Post WAL Error |
Date: | 2024-05-29 05:18:53 |
Message-ID: | Zla6vTUkFFDWgi_G@vault.lan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Tue, May 28, 2024 at 05:24:56PM -0400, Ron Johnson wrote:
> On Tue, May 28, 2024 at 3:11 PM Johannes Truschnigg <
> >[...]
> > Yes, replication slots can interrupt your primary.
> >
>
> Please define "interrupt". Using a replication slot, I thought files would
> just accumulate in pg_wal while the replica is down (or the network is
> slow, or the replica can't keep up with the primary).
>
> Disaster, of course, when that disk fills up, but that's always been the
> case.
And that is exactly the scenario I meant when I said "interrupt". If you use
replication slots, your monitoring/alerting isn't set up correctly, and you're
accumulating a lot of WAL, chances are ENOSPC on the primary is around the
corner for you.
That's why I generally prefer a WAL archive on a separate file system for
replicas to source segments from, because filling that up won't break the
primary (unless the archive_command misbehaves). That also needs proper
monitoring/alerting, of course (and a contingency plan for what to do when/if
the archive runs over) - but everyone whose workload is important enough for a
replication setup to make sense is required to have that in my book.
--
with best regards:
- Johannes Truschnigg ( johannes(at)truschnigg(dot)info )
From | Date | Subject | |
---|---|---|---|
Next Message | Charles Schultz | 2024-05-29 12:27:17 | Questions on recovery situations (not urgent) |
Previous Message | Zaid Shabbir | 2024-05-29 03:01:31 | Re: Pg_squeze |