Horton

Re: Standalone synchronous master

Florian G. Pflug <fgp@phlo.org>

View thread View on postgr.es
From: Florian Pflug <fgp@phlo.org>
To: Josh Berkus <josh@agliodbs.com>
Cc: Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@2ndquadrant.com>, "Joshua D. Drake" <jd@commandprompt.com>, Amit Kapila <amit.kapila16@gmail.com>, Hannu Krosing <hannu@2ndquadrant.com>, MauMau <maumau307@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <kgrittn@ymail.com>, Heikki Linnakangas <hlinnakangas@vmware.com>, Simon Riggs <simon@2ndquadrant.com>, Rajeev rastogi <rajeev.rastogi@huawei.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2014-01-13T15:12:27Z
Lists: pgsql-hackers 
On Jan12, 2014, at 04:18 , Josh Berkus <josh@agliodbs.com> wrote:
> Thing is, when we talk about auto-degrade, we need to determine things
> like "Is the replica down or is this just a network blip"? and take
> action according to the user's desired configuration.  This is not
> something, realistically, that we can do on a single request.  Whereas
> it would be fairly simple for an external monitoring utility to do:
> 
> 1. decide replica is offline for the duration (several poll attempts
> have failed)
> 
> 2. Send ALTER SYSTEM SET to the master and change/disable the
> synch_replicas.
> 
> 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.

best regards,
Florian Pflug