Re: Unexpected WAL-archive restore behaviour

On 02/18/2017 10:01 PM, Nikolay Petrov wrote:
> Hot standby server was started with new recovery.conf, reached
> consistent recovery state and resumed to restore WAL segments from
> archive. When couple of next wal segments became unavailable slave
> server just "skipped" them, instead to start streaming WAL from
> primary:

What do you mean by "became unavailable"? The restore_command may be
called for segments that do not exist - that's expected, and I suspect
the "gzip: stdin: unexpected end of file" error messages are caused by that.

Then, on the next try, that WAL segment probably existed, so it got
restored. It's difficult to say what actually happened, because you've
only posted doctored log - for example nowhere in the log is a message
that the standby started streaming from the primary, i.e. something like
this:

LOG: started streaming WAL from primary at 18/DE000000 on timeline 1

But maybe not - it's possible this happening because the archive and
restore commands are not atomic. E.g. let's say the restore_command gets
executed while the WAL segment is still being archived. In that case
it'll find an incomplete gzip archive, will try to decompress it, and
will fail with exactly the same ('unexpected end of file') error.

So I think you should read the docs about archive/restore command
requirements [1] and maybe also the wiki page about setting warm standby
[2]:

[1] https://www.postgresql.org/docs/9.6/static/continuous-archiving.html

[2] https://wiki.postgresql.org/wiki/Warm_Standby

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services