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@xxxxxxxxxxx
