Robert Haas <robertmhaas@gmail.com> writes:
> 1. Everything is humming along.
> 2. The network link between the master and standby drops.
> 3. Then it comes back up again.
>
> After (2) and before (3), what should the behavior the master be? It
> seems clear to me that it should WAIT. Otherwise, a crash on the
That just means you want data high availability, not service HA. Some
people want the *service* to stay available in such a situation.
> master now leaves you with transactions that were confirmed committed
> but not actually replicated to the standby. If you were OK with that
> scenario, you would have used asynchronous replication in the first
> place.
What is so hard to understand in "worst case scenario" being different
than "expected conditions". We all know that getting the last percent
is more expensive than getting the 99 first one. We have no reason to
force people into building for the last percent whatever their context.
So, what cases need to be defined wrt forbidding the primary to continue
alone?
- in flight commit
blocked until we can offer the asked for durability, wait forever
- shutdown request
blocked until standby acknowledge the final checkpoint
are immediate shutdown requests permitted? what do they do?
What other cases are to be fully designed here? Please note that above
list is just a way to start the design, not a definitive proposal from
me.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
