From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Mai Peng <maily(dot)peng(at)webedia-group(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Important lag in replication streaming between master and standby |
Date: | 2019-08-26 15:43:16 |
Message-ID: | CAMkU=1wZRTtJp32tbQo7+Y1H+xaOBqKLOWKT+j6j8TzG2u8DAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mon, Aug 26, 2019 at 11:21 AM Mai Peng <maily(dot)peng(at)webedia-group(dot)com>
wrote:
> Hello,
>
> I’ve got several times this error : "requested WAL segment
> 000000020000A01A0000004F has already been remove". I think it’s due to the
> lag between our master in EU zone and our standby in US zone.
> How could we configure Postgres to handle this issue?
>
You can increase wal_keep_segments so that the master keeps more segments
around for the standy to stream. This has the risk that you still won't
set it high enough and so might not actually solve the problem.
You can use a replication slot, which will force the master to keep the
segments until the standby streams them. This has the risk that the pg_wal
can grow without bound (if the standby can't keep up, or if it goes
offline), and the master will fill up its storage and crash (running out of
storage on the pg_wal directory is not handled very gracefully).
You can set up a wal archive, and then set up the replica so it can fetch
from that archive as a backstop to streaming. As a bonus, WAL files
usually compress very well, and if you compress them during archival you
can save a lot of network bandwidth when the standby needs to retrieve
them.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | soumitra bhandary | 2019-08-26 15:45:52 | Re: Important lag in replication streaming between master and standby |
Previous Message | Mai Peng | 2019-08-26 15:21:17 | Important lag in replication streaming between master and standby |