> On 02/18/2017 02:06, Tomas Vondra wrote:
>
> 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.
>
Sorry for my unclear description. I've attached a full slave server log file.
"became unavailable" - i mean that another shell script on master removed necessary WAL segments from archive
(segments,which hadn't applyed on slave server).
Here a detailed log of actions:
10:18 replication is working normally, physical replication slot was active and shipped WAL records.
10:19 I stoped slave to make changes in recovery.conf. Master server continued to archive WAL segments, replication
slothad become inactive.
10:54 I started the slave server, it reached consistent state and resumed to restore WAL segments from archive.
11:25 Replication slot on the master server was still inactive, it was waiting for connection. Slave was still reading
WALarchive segments and was applying them according recovery_min_apply_delay = 30min.
11:27 On master server was started bash script to remove old unnecessary WAL archive segments. Unfortunately in this
caseshell script has removed 3 necessary WAL segments, which was not applied on slave server yet. Usually, when WAL
archivesegments unavailable, slave-server starts streaming WAL from primary, but in this case slave continued to
restoreWAL from archive.
According documentation it's normal, when standby server looks for WAL segments that does not exists. In my case, WAL
segmentswas created by master server normally, but wasn't shipped to slave correctly. I am worrying about possible
slaveconsistency damaging.
Thank you for suggestions.
Regards.