| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | Mariya Rampurawala <Mariya(dot)Rampurawala(at)veritas(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: [EXTERNAL] Re: PostgreSQL-12 replication failover, pg_rewind fails |
| Date: | 2020-05-12 15:29:50 |
| Message-ID: | faea10fbbfaa619467c31df9eefab755b9b42e80.camel@cybertec.at |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | github kran | 2020-05-12 15:40:25 | Re: AutoVacuum and growing transaction XID's |
| Previous Message | Adrian Klaver | 2020-05-12 15:14:53 | Re: ESQL/C: a ROLLBACK rolls back a COMMITED transaction |