On 08/13/2018 05:08 AM, Phil Endecott 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.
>
> 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.
See also my reply to Stephen earlier. Basically you are trying to
coordinate two different operations. They start from the same source
pg_xlog(pg_wal 10+) but arrive on a different time scale and from
different locations. Without sufficient sanity checks it is possible
they diverge enough on one or both paths to render the process unstable.
>
> If that's not true, I think the docs need an even more extensive
> overhaul! Suggestion for the paragraph that I quoted before from
> 26.2.5:
>
> "If you set up a WAL archive that's accessible from the standby,
> it's anyone's guess what is appropriate for wal_keep_segments."
I would say that:
"If you set up a WAL archive that's accessible from the standby, these
solutions are not required, since the standby can always use the archive
to catch up provided it retains enough segments."
should be more like:
"If you set up a WAL archive that's accessible from the standby, these
solutions are not required, since the standby can always use the archive
to catch up provided it retains enough segments. *This is dependent on
verification that the archiving is working properly. A belt and
suspenders approach would be to set wal_keep_segments to a value > 0 in
the event archiving is not properly functioning*"
"
>
>
> Regards, Phil.
>
>
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com