Re: Configuring synchronous replication
От | Josh Berkus |
---|---|
Тема | Re: Configuring synchronous replication |
Дата | |
Msg-id | 4C994827.1030403@agliodbs.com обсуждение исходный текст |
Ответ на | Re: Configuring synchronous replication (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Configuring synchronous replication
|
Список | pgsql-hackers |
> That said, the timeout option also feels a bit wishy-washy to me. With a > timeout, acknowledgment of a commit means "your transaction is safely > committed in the master and slave. Or not, if there was some glitch with > the slave". That doesn't seem like a very useful guarantee; if you're > happy with that why not just use async replication? Ah, I wasn't clear. My thought was that a standby which exceeds the timeout would be marked as "nonresponsive" and no longer included in the list of standbys which needed to be synchronized. That is, the timeout would be a timeout which says "this standby is down". > So the only case where standby registration is required is where you > deliberately choose to *not* have N+1 redundancy and then yet still > require all N standbys to acknowledge. That is a suicidal config and > nobody would sanely choose that. It's not a large or useful use case for > standby reg. (But it does raise the question again of whether we need > quorum commit). Thinking of this as a sysadmin, what I want is to have *one place* I can go an troubleshoot my standby setup. If I have 12 synch standbys and they're creating too much load on the master, and I want to change half of them to async, I don't want to have to ssh into 6 different machines to do so. If one standby needs to be taken out of the network because it's too slow, I want to be able to log in to the master and instantly identify which standby is lagging and remove it there. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com
В списке pgsql-hackers по дате отправления: