On 02/28/2017 02:20 PM, Sasa Vilic wrote:
On 2017-02-28 16:41, Adrian Klaver wrote:
Seems to mean the simpler thing to do would be to set standby to
archive_mode = on, in which case the standby would not contribute WAL's
until it was promoted which would seem to be what you want.
Yes, that was my first thought. Except that documentation states following:
"""
If archive_mode is set to on, the archiver is not enabled during
recovery or standby mode. If the standby server is promoted, it will
start archiving after the promotion, *but will not archive any WAL it
did not generate itself*
"""
What happens with WAL that are started on primary but finished on
secondary?
I thought that was covered in your scenario?:
"
5. Primary server crashes, i.e. due to catastrophic disk failure
- everything stops and can't be recovered
- wal archiver is dead, but even if it were alive it wouldn't send
WAL to archive anyway because 16MB of wal segment was not filled up
6. We promote our secondary server to master
- In secondary server's WAL we already got changes from primary
- Secondary continues appending new changes to wal segment
7. Eventually WAL segment on secondary fills up and then pushes it to
wal archive.
"
So the WAL that is sent to the archive by the standby is the one it
generated from the records it got via streaming replication from the master.
Regards,
Sasa
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
