On 01/09/2014 05:09 AM, Robert Treat wrote: > On Wed, Jan 8, 2014 at 6:15 PM, Josh Berkus <j...@agliodbs.com> wrote: >> Stephen, >> >> >>> I'm aware, my point was simply that we should state, up-front in >>> 25.2.7.3 *and* where we document synchronous_standby_names, that it >>> requires at least three servers to be involved to be a workable >>> solution. >> It's a workable solution with 2 servers. That's a "low-availability, >> high-integrity" solution; the user has chosen to double their risk of >> not accepting writes against never losing a write. That's a perfectly >> valid configuration, and I believe that NTT runs several applications >> this way. >> >> In fact, that can already be looked at as a kind of "auto-degrade" mode: >> if there aren't two nodes, then the database goes read-only. >> >> Might I also point out that transactions are synchronous or not >> individually? The sensible configuration is for only the important >> writes being synchronous -- in which case auto-degrade makes even less >> sense. >> >> I really think that demand for auto-degrade is coming from users who >> don't know what sync rep is for in the first place. The fact that other >> vendors are offering auto-degrade as a feature instead of the ginormous >> foot-gun it is adds to the confusion, but we can't help that. >> > I think the problem here is that we tend to have a limited view of > "the right way to use synch rep". If I have 5 nodes, and I set 1 > synchronous and the other 3 asynchronous, I've set up a "known > successor" in the event that the leader fails. But there is no guarantee that the synchronous replica actually is ahead of async ones.
> In this scenario > though, if the "successor" fails, you actually probably want to keep > accepting writes; since you weren't using synchronous for durability > but for operational simplicity. I suspect there are probably other > scenarios where users are willing to trade latency for improved and/or > directed durability but not at the extent of availability, don't you? > 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
