Shaun Thomas <sthomas@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