RE: replication followup
От | Mikheev, Vadim |
---|---|
Тема | RE: replication followup |
Дата | |
Msg-id | 8F4C99C66D04D4118F580090272A7A234D3233@sectorbase1.sectorbase.com обсуждение исходный текст |
Ответ на | replication followup (Justin Banks <justinb@wamnet.com>) |
Ответы |
RE: replication followup
|
Список | pgsql-general |
Two comments about sync replication: 1. You cannot do true sync replication without two-phase commit protocol. (What if transaction will be committed on slave but master will be stopped/crashed/whatever? Databases will be out of sync). 2. You cannot do bi-directional sync replication without distributed lock manager. (You'll get deadlock when attempting update "same" record - ie with the same key - on two sites at the same time). Vadim P.S. Are you sure that -general is right list for this stuff? > As a followup to my mail about replication yesterday, I've > realized that I can make replication bi-directional, with each > (non-replicant master initiated) connection to a backend it's own > master with respect to that connection and all data > modifications made > within it. In order to do that, though, I need to add items to the > structs Port (be) and PGconn (fe). After I do that, the asynch stuff > would just fall into place, and the performance should impove. My > question is whether there is anything I should be really careful of > when modifying these structs? I'm not sure if there is code that uses > byte offsets or something into these structs, so any warnings > would be > much appreciated. > > On a related note, does anyone know what the status of ER's > replication is? > > -justinb > > -- > Justin Banks - WAM!NET Inc., Eagan MN justinb@wamnet.com > When you find two people who agree completely, you can be pretty > sure that exactly one of them is doing the thinking. > >
В списке pgsql-general по дате отправления: