On 01/09/2014 02:01 AM, Jim Nasby wrote: > On 1/8/14, 6:05 PM, Tom Lane wrote: >> Josh Berkus<j...@agliodbs.com> writes: >>> >On 01/08/2014 03:27 PM, Tom Lane wrote: >>>> >>What we lack, and should work on, is a way for sync mode to have >>>> M larger >>>> >>than one. AFAICS, right now we'll report commit as soon as >>>> there's one >>>> >>up-to-date replica, and some high-reliability cases are going to >>>> want >>>> >>more. >>> >"Sync N times" is really just a guarantee against data loss as long as >>> >you lose N-1 servers or fewer. And it becomes an even >>> >lower-availability solution if you don't have at least N+1 replicas. >>> >For that reason, I'd like to see some realistic actual user demand >>> >before we take the idea seriously. >> Sure. I wasn't volunteering to implement it, just saying that what >> we've got now is not designed to guarantee data survival across failure >> of more than one server. Changing things around the margins isn't >> going to improve such scenarios very much. >> >> It struck me after re-reading your example scenario that the most >> likely way to figure out what you had left would be to see if some >> additional system (think Nagios monitor, or monitors) had records >> of when the various database servers went down. This might be >> what you were getting at when you said "logging", but the key point >> is it has to be logging done on an external server that could survive >> failure of the database server. postmaster.log ain't gonna do it. > > Yeah, and I think that the logging command that was suggested allows > for that *if configured correctly*. *But* for relying on this, we would also need to make logging *synchronous*, which would probably not go down well with many people, as it makes things even more fragile from availability viewpoint (and slower as well).
Cheers -- Hannu Krosing PostgreSQL Consultant Performance, Scalability and High Availability 2ndQuadrant Nordic OÜ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
