Thread: replication followup
Hello -
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.
On Fri, 5 Jan 2001, Justin Banks wrote: > Hello - > 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? It was comitted to the source tree, under contrib, before Xmas, and will be in the beta2 distribution schedualed for this weekend ...
How do we get it? I want to test the product. Sandeep > On Fri, 5 Jan 2001, Justin Banks wrote: > > > Hello - > > 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? > > It was comitted to the source tree, under contrib, before Xmas, and will > be in the beta2 distribution schedualed for this weekend ...
>>>>> "Sandeep" == Sandeep Joshi <sjoshi@Zambeel.com> writes: Sandeep> How do we get it? I want to test the product. I'm going to do a little more work on it right now, and I'll certainly email/whatever it to you when I'm done. I've developed it on SGI, but it should run fine wherever dlopen() and dlsym() are supported. I'll test it on linux and solaris before I hand it to anybody else. I'll make it available (most likely via ftp) on this coming Monday. >> It was comitted to the source tree, under contrib, before Xmas, >> and will be in the beta2 distribution schedualed for this weekend >> ... Aaah. I should have known that if I came up with something by myself, it would become available shortly thereafter ;) Perhaps there's no point, then. -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.
On Fri, 5 Jan 2001, Sandeep Joshi wrote: > How do we get it? > I want to test the product. downloadable as a tar file from http://www.pgsql.com -> Download ... > > Sandeep > > > On Fri, 5 Jan 2001, Justin Banks wrote: > > > > > Hello - > > > 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? > > > > It was comitted to the source tree, under contrib, before Xmas, and will > > be in the beta2 distribution schedualed for this weekend ... > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
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. > >
>>>>> "Mikheev" == Mikheev, Vadim <vmikheev@SECTORBASE.COM> writes: Mikheev> Two comments about sync replication: Mikheev> 1. You cannot do true sync replication without two-phase Mikheev> commit protocol. (What if transaction will be committed on Mikheev> slave but master will be stopped/crashed/whatever? Databases Mikheev> will be out of sync). I have addressed this in the code I have working now. I was hoping to get the current code out to some interested parties today, but I fell into a couple meetings, and it may be a day or so. Mikheev> 2. You cannot do bi-directional sync replication without Mikheev> distributed lock manager. (You'll get deadlock when Mikheev> attempting update "same" record - ie with the same key - on Mikheev> two sites at the same time). I encountered that realization today ;) I think I'm going to have to stick with unidirectional, but I need to think about it some more. There may be ways that I can do it properly in my particular case, but I'm sure you're right in the general case. I have some ideas, though, if you'd be interested we could take that discussion off the list somewhere? Mikheev> Vadim P.S. Are you sure that -general is right list for this Mikheev> stuff? Nope, as I stated in my original email, but I wasn't sure. Is -hackers perhaps a better place? -justinb -- Justin Banks - WAM!NET Inc., Eagan MN justinb@wamnet.com "I can't stand this proliferation of paperwork. It's useless to fight the forms. You've got to kill the people producing them." --Vladimir Kabaidze, General Director of Ivanovo Machine Building Works