Re: Sync Rep Design
Greg Smith <greg@2ndquadrant.com>
From: Greg Smith <greg@2ndquadrant.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Josh Berkus <josh@agliodbs.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Hannu Krosing <hannu@2ndquadrant.com>, Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>, pgsql-hackers@postgresql.org
Date: 2011-01-05T01:59:57Z
Lists: pgsql-hackers
Simon Riggs wrote: > Based upon that series of conversations, I've reworked the design so > that there is (currently) only a single standby offering sync rep at any > one time. Other standbys can request to be sync standbys but they only > become the sync standby if the first one fails. Which was simple to do > and bridges the challenges of an exactly identified sync standby and the > fragility of too closely specifying the config. > That seems like a good enough starting point to cover a lot of cases. Presuming the two servers each at two sites config that shows up in a lot of these discussions, people in the "I need sync to a remote spot" can get that, and if that site is unavailable for long enough to be kicked out they'll smoothly degrade to sync on a secondary local copy. And those who want high performance local sync and best-effort for the remote site can configure for that too, and if the local secondary dies they'll just degrade to the slow remote commits. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books