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.
Thereis 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
thatthe master and standby are in the same state. As Josh Berkus pointed out there is a loop hole in this when multiple
standbysare 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%
reliableslave. 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
connectionfailure, 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
ignorethat 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
Postgresthen I think a good compromise would be to have an external project that does just that and have the docs
referencethat project and explain why we haven't built it in.
--
Jim C. Nasby, Data Architect jim@nasby.net
512.569.9461 (cell) http://jim.nasby.net