Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node
От | Andres Freund |
---|---|
Тема | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node |
Дата | |
Msg-id | 201206202127.54053.andres@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH 10/16] Introduce the concept that wal has a 'origin' node (Aidan Van Dyk <aidan@highrise.ca>) |
Ответы |
Re: [PATCH 10/16] Introduce the concept that wal has a
'origin' node
|
Список | pgsql-hackers |
On Wednesday, June 20, 2012 09:24:29 PM Aidan Van Dyk wrote: > On Wed, Jun 20, 2012 at 3:15 PM, Andres Freund <andres@2ndquadrant.com> wrote: > > To recap why we think origin_id is a sensible design choice: > > > > There are many sensible replication topologies where it does make sense > > that you want to receive changes (on node C) from one node (say B) that > > originated from some other node (say A). > > Reasons include: > > * the order of applying changes should be as similar as possible on all > > nodes. That means when applying a change on C that originated on B and > > if changes replicated faster from A->B than from A->C you want to be at > > least as far with the replication from A as B was. Otherwise the > > conflict ratio will increase. If you can recreate the stream from the > > wal of every node and still detect where an individual change > > originated, thats easy. > > OK, so in this case, I still don't see how the "origin_id" is even enough. > > C applies the change originally from A (routed through B, because it's > faster). But when it get's the change directly from A, how does it > know to *not* apply it again? The lsn of the change. Andres -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: