| From: | Jim Nasby <jim(at)nasby(dot)net> |
|---|---|
| To: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>, MauMau <maumau307(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Standalone synchronous master |
| Date: | 2014-01-11 00:51:41 |
| Message-ID: | 52D0959D.5020003@nasby.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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 jim(at)nasby(dot)net
512.569.9461 (cell) http://jim.nasby.net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2014-01-11 00:57:04 | Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb |
| Previous Message | Peter Geoghegan | 2014-01-11 00:51:21 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |