Re: Postgresql 9.5: Streaming Replication: Secondaries Fail To Start Post WAL Error

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 )

www: https://johannes.truschnigg.info/

In response to

Responses

Browse pgsql-admin by date

  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