Re: Replication failure, slave requesting old segments

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Phil Endecott <spam_from_pgsql_lists(at)chezphil(dot)org>
Cc: pgsql-general(at)lists(dot)postgresql(dot)org, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Subject: Re: Replication failure, slave requesting old segments
Date: 2018-08-13 12:39:15
Message-ID: 20180813123915.GD3326@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greetings,

* Phil Endecott (spam_from_pgsql_lists(at)chezphil(dot)org) wrote:
> Adrian Klaver wrote:
> >On 08/12/2018 02:56 PM, Phil Endecott wrote:
> >>Anyway.  Do others agree that my issue was the result of
> >>wal_keep_segments=0 ?
> >
> >Only as a sub-issue of the slave losing contact with the master. The basic
> >problem is maintaining two separate operations, archiving and streaming,
> >in sync. If either or some combination of both lose synchronization then
> >it is anyone's guess on what is appropriate for wal_keep_segments.

Uh, no, having an archive_command and a restore_command configures
exactly should remove the need to worry about what wal_keep_segments is
set to because anything not on the primary really should be available
through what's been archived and PG shouldn't have any trouble figuring
that out and working with it.

If all you've got is streaming replication then, sure, you have no idea
what to set wal_keep_segments to because the replica could be offline
for an indeterminate amount of time, but as long as you're keeping track
of all the WAL through archive_command, that shouldn't be an issue.

> Really? I thought the intention was that the system should be
> able to recover reliably when the slave reconnects after a
> period of downtime, subject only to there being sufficient
> network/CPU/disk bandwidth etc. for it to eventually catch up.

Yes, that's correct, the replica should always be able to catch back up
presuming there's no gaps in the WAL between when the replica failed and
where the primary is at.

Thanks!

Stephen

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2018-08-13 13:32:21 Re: How to get connection details from psql -> \e
Previous Message Tomas Vondra 2018-08-13 12:35:06 Re: is there any adverse effect on DB if I set autovacuum scale factor to zero?