Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication.
От | MARK CALLAGHAN |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Дата | |
Msg-id | AANLkTi=B+cWE-pQJQM=zoA9=Zr25W7zPPMFvvBe11O4E@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. (Markus Wanner <markus@bluegap.ch>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled
synchronous replication.
Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. |
Список | pgsql-hackers |
On Fri, Mar 18, 2011 at 9:27 AM, Markus Wanner <markus@bluegap.ch> wrote: > Google invented the term "semi-syncronous" for something that's > essentially the same that we have, now, I think. However, I full > heartedly hate that term (based on the reasoning that there's no > semi-pregnant, either). We didn't invent the term, we just implemented something that Heikki Tuuri briefly described, for example: http://bugs.mysql.com/bug.php?id=7440 In the Google patch and official MySQL version, the sequence is: 1) commit on master 2) wait for slave to ack 3) return to user After step 1 another user on the master can observe the commit and the following is possible: 1) commit on master 2) other user observes that commit on master 3) master blows up and a user observed a commit that never made it to a slave I do not think this sequence should be possible in a sync replication system. But it is possible in what has been implemented for MySQL. Thus it was named semi-sync rather than sync. -- Mark Callaghan mdcallag@gmail.com
В списке pgsql-hackers по дате отправления: