Re: Replication
От | Markus Schiltknecht |
---|---|
Тема | Re: Replication |
Дата | |
Msg-id | 44EC80FB.4040800@bluegap.ch обсуждение исходный текст |
Ответ на | Re: Replication (Hannu Krosing <hannu@skype.net>) |
Список | pgsql-hackers |
Hi, Hannu Krosing wrote: > but it still needs to do at least one network roundtrip + any needed > testing on all nodes + WAL sync on all nodes before it can COMMIT, no? No. It only needs the 'roundtrip' in the sense that a transaction sends out its writeset and has to wait for the GCS to have it serialized (i.e. the GCS sends the message back to the sender node). Then all nodes do the testing and WAL sync independently. (As Neil recently pointed out in [1] this opens a small risk for data loss in the case all nodes crash.) > And I'm afraid that GCS serialisation will need more than one roundtrip > or risk being out-of-date. The spread people did some tests on 20 pentium machines connected via 100mbit ethernet. In [2] they state that it takes between 1.7 to 2.8 ms (depending on the message size) to 'serialize' a message within this group of 20 nodes. > I'm not saying that Postgres-R (or any other sync replication) is not > doable or even useful. I just can't see right away, how it can scale > very well for any significant write load. Sure, sync replication won't solve everybody's problems. But out of all the sync replication algorithms, Postgres-R is my clear favorite. ;-) Regards Markus [1]: http://pgfoundry.org/pipermail/postgres-r-general/2006-August/000001.html [2]: The Spread Toolkit: Architecture and Performance by Yair Amir, Claudiu Danilov, Michal Miskin-Amir, John Schultz, Jonathan Stanton http://www.cnds.jhu.edu/pub/papers/cnds-2004-1.pdf
В списке pgsql-hackers по дате отправления: