Because standby is running in syncronous replication, whereby wal archiver is asynchronous. Therefore there is a small window where slave has received the data but master has not pushed it yet to wal archive.
Master is streaming directly to standby. Both master and standby are pushing WALs to archive.
My point is that in case that master crashed completely (and we failover to standby) and wal archiver on master didn't push everything to wal archive, we would still have a wal pushed from slave. Therefore there is no interruption in WAL stream.
Still failing to see how the standby can have more information then what the master had sent to it at the time of the crash.
I am trying to setup shared WAL archive between master and standby. Standby is synchronously streaming from master and both servers run with archive_mode = always. The ideas is that when promoting standby to master we would not missed WALs.
I seem to be missing the point of duplicating your effort.
I can't see how the Standby contributes anything to the archive that it does not already have from the Master?
My problem is that sometimes WAL uploaded from master and from slave are not 100% identical. In most cases they are but occasionally they are not. I have written small script that ensures that upload is free of race condition and I log md5 sum of each WAL. Aren't WALs from master and standby supposed to be identical? After all, standby is just consuming WAL that it is receiving from master ...
Or do you have any better suggestion on how to achieve continuous incremental backup?
