Hi Adrian,
Adrian Klaver wrote:
On 08/11/2018 12:42 PM, Phil Endecott wrote:
Hi Adrian,
Adrian Klaver wrote:
Looks like the master recycled the WAL's while the slave could not
connect.
Yes but... why is that a problem? The master is copying the WALs to
the backup server using scp, where they remain forever. The slave gets
To me it looks like that did not happen:
2018-08-11 00:05:50.364 UTC [615] LOG: restored log file
"0000000100000007000000D0" from archive
scp: backup/postgresql/archivedir/0000000100000007000000D1: No such file
or directory
2018-08-11 00:05:51.325 UTC [7208] LOG: started streaming WAL from
primary at 7/D0000000 on timeline 1
2018-08-11 00:05:51.325 UTC [7208] FATAL: could not receive data from
WAL stream: ERROR: requested WAL segment 0000000100000007000000D0 has
already been removed
Above 0000000100000007000000D0 is gone/recycled on the master and the
archived version does not seem to be complete as the streaming
replication is trying to find it.
The files on the backup server were all 16 MB.
Below you kick the master and it coughs up the files to the archive
including *D0 and *D1 on up to *D4 and then the streaming picks using *D5.
When I kicked it, the master wrote D1 to D4 to the backup. It did not
change D0 (its modification time on the backup is from before the "kick").
The slave re-read D0, again, as it had been doing throughout this period,
and then read D1 to D4.
Best guess is the archiving did not work as expected during:
"(During this time the master was also down for a shorter period.)"
Around the time the master was down, the WAL segment names were CB and CC.
Files CD to CF were written between the master coming up and the slave
coming up. The slave had no trouble restoring those segments when it started.
The problematic segments D0 and D1 were the ones that were "current"
when the
slave restarted, at which time the master was up consistently.
Regards, Phil.
