On 1/10/14, 6:19 PM, Adrian Klaver wrote:
1) Async. Runs at the speed of the master as it does not have to wait on the
standby to signal a successful commit. There is some degree of offset between
master and standby(s) due to latency.
2) Sync. Runs at the speed of the standby + latency between master and standby.
This is counter balanced by knowledge that the master and standby are in the
same state. As Josh Berkus pointed out there is a loop hole in this when
multiple standbys are involved.
The topic under discussion is an intermediate mode between 1 and 2. There seems
to be a consensus that this is not unreasonable.
That's not what's actually under debate; allow me to restate as option 3:
3) Sync. Everything you said, plus: "If for ANY reason the master can not talk to
the slave it becomes read-only."
That's the current state.
What many people want is something along the lines of what you said in 2: The
slave ALWAYS has everything the master does (at least on disk) unless the
connection between master and slave fails.
The reason people want this is it protects you against a *single* fault. If
just the master blows up, you have a 100% reliable slave. If the connection (or
the slave itself) blows up, the master is still working.
I agree that there's a non-obvious gotcha here: in the case of a master failure
you might also have experienced a connection failure, and without some kind of
3rd party involved you have no way to know that.
We should make best efforts to make that gotcha as clear to users as we can.
But just because some users will blindly ignore that doesn't mean we flat-out
shouldn't support those that will understand the gotcha and accept it's
limitations.
BTW, if ALTER SYSTEM SET actually does make it possible to implement automated
failover without directly adding it to Postgres then I think a good compromise
would be to have an external project that does just that and have the docs
reference that project and explain why we haven't built it in.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
