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.
Regards,
Sasa
Am 28.02.2017 02:48 schrieb "Adrian Klaver" <adrian.klaver@xxxxxxxxxxx>:
On 02/27/2017 05:29 PM, Sasa Vilic wrote:
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.
Regards,
Sasa
On 28 February 2017 at 01:57, Adrian Klaver <adrian.klaver@xxxxxxxxxxx
<mailto:adrian.klaver@aklaver.com >> wrote:
On 02/27/2017 04:40 PM, Sasa Vilic wrote:
Hallo,
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.
You are doing this, correct?:
Master WAL --> WAL archive <--
|
Master stream --> Standby --> |
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?
Thanks in advance
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx <mailto:adrian.klaver@aklaver.com >
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx