I'm trying to wrap my head around Postgres' asynchronous replication. The way I'm reading the documentation, if the master goes down after data was committed, but before it's shipped to slaves, the slaves will never get that data (even after the master goes back up).

This, as I understand it, is different than MySQL's async replication, where the master resumes syncing it's binary log once it's brought back up (without any data loss).

Seems a bit crazy to me, so I wanted to make sure I was reading the docs properly.

To be clear, I'm not talking about data loss resulting in electing one of the slaves as the new master. Simply data loss with respect to the master going down before the WAL is shipped and it not being shipped once the master comes back up.

1 Answer 1


When the master comes back up, any left-over WAL must be synced to the slave, otherwise the slave won't be able to carry on as a replica. At that point the slave will replay the WAL and be caught up with the master. No data is lost so long as the master comes back up. You only lose not-yet-replicated data if you lose the master.

This is guaranteed by the timeline; the slaves simply refuse to replay WAL archives except in the correct and unbroken timeline order. So long as you're correctly monitoring your slave nodes you'll see them stop advancing and know things are broken. This shouldn't happen if WAL archiving is set up properly, though.

Consider using async streaming replication as well as WAL shipping, that helps reduce the potential loss window if you do lose the master.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.