Shaun Thomas <stho...@optionshouse.com> writes: > When you re-connect a secondary device, it catches up as fast as possible by > replaying waiting transactions, and then re-attaching to the cluster. Until > it's fully caught-up, it doesn't exist. DRBD acknowledges the secondary is > there and attempting to catch up, but does not leave "degraded" mode until > the secondary reaches "UpToDate" status.
That's exactly what happens with PostgreSQL when using asynchronous replication and archiving. When joining the cluster, the standby will feed from the archives and then there's nothing recent enough left over there, and only at this time it will contact the master. For a real graceful setup you need both archiving and replication. Then, synchronous replication means that no transaction can make it to the master alone. The use case is not being allowed to tell the client it's ok when you're at risk of losing the transaction by crashing the master when it's the only one knowing about it. What you explain you want reads to me "Async replication + Archiving". Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
