On 01/13/2014 10:12 AM, Hannu Krosing wrote:
>>> In other words, if we're going to have auto-degrade, the most
>>> intelligent place for it is in
>>> RepMgr/HandyRep/OmniPITR/pgPoolII/whatever. It's also the *easiest*
>>> place. Anything we do *inside* Postgres is going to have a really,
>>> really hard time determining when to degrade.
>> +1
>>
>> This is also how 2PC works, btw - the database provides the building
>> blocks, i.e. PREPARE and COMMIT, and leaves it to a transaction manager
>> to deal with issues that require a whole-cluster perspective.
>>
>
> ++1
+1
>
> I like Simons idea to have a pg_xxx function for switching between
> replication modes, which should be enough to support a monitor
> daemon doing the switching.
>
> Maybe we could have an 'syncrep_taking_too_long_command' GUC
> which could be used to alert such a monitoring daemon, so it can
> immediately check weather to
>
I would think that would be a column in pg_stat_replication. Basically
last_ack or something like that.
> a) switch master to async rep or standalone mode (in case of sync slave
> becoming unavailable)
Yep.
>
> or
>
> b) to failover to slave (in almost equally likely case that it was the
> master
> which became disconnected from the world and slave is available)
>
> or
I think this should be left to external tools.
JD
--
Command Prompt, Inc. - http://www.commandprompt.com/ 509-416-6579
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, Postgres-XC, @cmdpromptinc
"In a time of universal deceit - telling the truth is a revolutionary
act.", George Orwell