Re: Sync Rep Design
От | Simon Riggs |
---|---|
Тема | Re: Sync Rep Design |
Дата | |
Msg-id | 1293901428.1892.60565.camel@ebony обсуждение исходный текст |
Ответ на | Re: Sync Rep Design (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: Sync Rep Design
|
Список | pgsql-hackers |
On Sat, 2011-01-01 at 17:37 +0100, Stefan Kaltenbrunner wrote: > On 01/01/2011 05:28 PM, Dimitri Fontaine wrote: > > Stefan Kaltenbrunner<stefan@kaltenbrunner.cc> writes: > >> well you keep saying that but to be honest I cannot really even see a > >> usecase for me - what is "only a random one of a set of servers is sync at > >> any time and I don't really know which one". > > > > It looks easy enough to get to know which one it is. Surely the primary > > knows and could update something visible through a system view for > > users? This as been asked for before and I was thinking there was a > > consensus on this. > > well as jeff janes already said - anything that requires the master to > still exist is not useful for a desaster. Nobody has suggested that the master needs to still exist after a disaster. > Consider the now often > mentioned 2 sync standby scenario with one standby in the same location > and one in a secondary location. > If you have a desaster(fire,water,explosion,admin fail,...) at the > primary location and you have no access to either the master or the > standby you will never be sure that the standby on the secondary > location is actually "in sync" - it could be but you will never know if > you lost that 1B$ invoice just commited on the master and the closeby > standby and therefor confirmed to the client... I've never suggested you configure your systems like that. It would of course be stupid. This is not a sensible technical discussion. I'll go back to coding. -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: