Re: Standalone synchronous master
От | Josh Berkus |
---|---|
Тема | Re: Standalone synchronous master |
Дата | |
Msg-id | 52CDDC09.50301@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Standalone synchronous master (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: Standalone synchronous master
Re: Standalone synchronous master |
Список | pgsql-hackers |
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. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com
В списке pgsql-hackers по дате отправления: