Re: [EXTERNAL] Re: PostgreSQL-12 replication failover, pg_rewindfails - Mailing list pgsql-general

From Laurenz Albe
Subject Re: [EXTERNAL] Re: PostgreSQL-12 replication failover, pg_rewindfails
Date
Msg-id faea10fbbfaa619467c31df9eefab755b9b42e80.camel@cybertec.at
Whole thread Raw
In response to Re: [EXTERNAL] Re: PostgreSQL-12 replication failover, pg_rewindfails  (Mariya Rampurawala <Mariya.Rampurawala@veritas.com>)
Responses Re: [EXTERNAL] Re: PostgreSQL-12 replication failover, pg_rewindfails  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-general
On Tue, 2020-05-12 at 09:40 +0000, Mariya Rampurawala wrote:
> > but if the target cluster ran for a long time after the divergence,
> > the old WAL files might no longer be present. In that case, they can
> > be manually copied from the WAL archive to the pg_wal directory, or
> > fetched on startup by configuring primary_conninfo or restore_command.
> 
> I hit this issue every time I follow the aforementioned steps, manually as well as with scripts.
> How long is "long time after divergence"? Is there a way I can make some
> configuration changes so that I don’t hit this issue?
> Is there anything I must change in my restore command?

What you can do is to use a higher value for "wal_keep_segments".
Then PostgreSQL will keep around that number of old WAL segments,
which increases the chance for "pg_rewind" to succeed.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com




pgsql-general by date:

Previous
From: Adrian Klaver
Date:
Subject: Re: ESQL/C: a ROLLBACK rolls back a COMMITED transaction
Next
From: github kran
Date:
Subject: Re: AutoVacuum and growing transaction XID's