On Fri, Jul 13, 2012 at 10:22 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Fri, Jul 13, 2012 at 09:12:56AM +0200, Hampus Wessman wrote:
>> How you decide what to do with the servers on failures isn't that
>> important here, really. You can probably run e.g. Pacemaker on 3+
>> machines and have it check for quorums to accomplish this. That's a
>> good approach at least. You can still have only 2 database servers
>> (for cost reasons), if you want. PostgreSQL could have all this
>> built-in, but I don't think it sounds overly useful to only be able
>> to disable synchronous replication on the primary after a timeout.
>> Then you can never safely do a failover to the secondary, because
>> you can't be sure synchronous replication was active on the failed
>> primary...
>
> So how about this for a Postgres TODO:
>
> Add configuration variable to allow Postgres to disable synchronous
> replication after a specified timeout, and add variable to alert
> administrators of the change.
I agree we need a TODO for this, but... I think timeout-only is not
the best choice, there should be a maximum timeout (as a last
resource: the maximum time we are willing to wait for standby, this
have to have the option of "forever"), but certainly PostgreSQL have
to detect the *complete* disconnection of the standby (or all standbys
on the synchronous_standby_names), if it detects that no standbys are
eligible for sync standby AND the option to do fallback to async is
enabled = it will go into standalone mode (as if
synchronous_standby_names were empty), otherwise (if option is
disabled) it will just continue to wait for ever (the "last resource"
timeout is ignored if the fallback option is disabled).... I would
call this "soft_synchronous_standby", and
"soft_synchronous_standby_timeout" (in seconds, 0=forever, a sane
value would be ~5 seconds) or something like that (I'm quite bad at
picking names :( ).
--
Ildefonso Camargo
Command Prompt, Inc. - http://www.commandprompt.com/
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC
@cmdpromptinc - 509-416-6579