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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
