Re: Configuring synchronous replication
От | Simon Riggs |
---|---|
Тема | Re: Configuring synchronous replication |
Дата | |
Msg-id | 1284736940.1733.4998.camel@ebony обсуждение исходный текст |
Ответ на | Re: Configuring synchronous replication (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: Configuring synchronous replication
|
Список | pgsql-hackers |
On Fri, 2010-09-17 at 09:36 -0400, Aidan Van Dyk wrote: > I want to have them configured in a fsync WAL/style sync rep, I want to > make sure that if the master comes up first after I get power back, it's > not going to be claiming transactions are committed while the slave > (which happens to have 4x the disks because it keeps PITR backups for a > period too) it still chugging away on SCSI probes yet, not gotten to > having PostgreSQL up yet... Nobody has mentioned the ability to persist the not-committed state across a crash before, and I think it's an important discussion point. We already have it: its called "two phase commit". (2PC) If you run 2PC on 3 servers and one goes down, you can just commit the in-flight transactions and continue. But it doesn't work on hot standby. It could: If we want that we could prepare the transaction on the master and don't allow commit until we get positive confirmation from standby. All of the machinery is there. I'm not sure if that's a 5th sync rep mode, or that idea is actually good enough to replace all the ideas we've had up until now. I would say probably not, but we should think about this. A slightly modified idea would be avoid writing the transaction prepare file as a separate file, just write the WAL for the prepare. We then remember the LSN of the prepare so we can re-access the WAL copy of it by re-reading the WAL files on master. Make sure we don't get rid of WAL that refers to waiting transactions. That would then give us the option to commit or abort depending upon whether we receive a reply within timeout. -- Simon Riggs www.2ndQuadrant.comPostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: