Thread: Replication status
Hi, could anyone please enlighten me about the status of replication? I do expect lots of questions about this, and I'm not really sure if I can promise it for 7.3. :-) Yes, I know it's marked urgent in the TODO list, but no one seems to be listed as tackling this topic. Thanks a lot. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Michael Meskes <meskes@postgresql.org> writes:
> could anyone please enlighten me about the status of replication? I do
> expect lots of questions about this, and I'm not really sure if I can
> promise it for 7.3. :-)
Unless 7.3 slips drastically from our current intended schedule
(beta in late August), I think it's pretty safe to say there will
be no replication in 7.3, beyond what's already available (rserv
and so forth).
regards, tom lane
> > > >Unless 7.3 slips drastically from our current intended schedule >(beta in late August), I think it's pretty safe to say there will >be no replication in 7.3, beyond what's already available (rserv >and so forth). > I can't speak for any of the other replication projects, but pgreplication won't be ready for 7.3. If all goes according to plan, I should have some free time over the summer months to put a good dent in the first phase, but at best it would be a very limited experimental patch. More information on pgreplication can be found @ http://gborg.postgresql.org/project/pgreplication/projdisplay.php Darren
Tom Lane wrote: > Michael Meskes <meskes@postgresql.org> writes: > > could anyone please enlighten me about the status of replication? I do > > expect lots of questions about this, and I'm not really sure if I can > > promise it for 7.3. :-) > > Unless 7.3 slips drastically from our current intended schedule > (beta in late August), I think it's pretty safe to say there will > be no replication in 7.3, beyond what's already available (rserv > and so forth). Last I talked to Darren, the replication code was modified to merge into our 7.2 tree. There are still pieces missing so it will not be functional when applied. It is remotely possible there could be master-slave in 7.3, but I doubt it. I was hoping to spend major time on it myself (and SRA/Japan has encouraged me to get involved), but have been too busy to dive in. I think once it is in CVS, it will be easier to grasp what is going on, and perhaps to move it forward. I saw a message (I think for Darrren) saying he hoped to restart on it in two weeks. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Mon, May 27, 2002 at 05:12:33PM -0400, Bruce Momjian wrote: > Last I talked to Darren, the replication code was modified to merge into > our 7.2 tree. There are still pieces missing so it will not be > functional when applied. It is remotely possible there could be > master-slave in 7.3, but I doubt it. This is about pgreplication I think. Is the the replication project of choice for pgsql? IIRC there quite some projects for this topic: PostgreSQL replicator Rserver Usogres dbbalancer What about these? We seem to have some proof-of-concept code of rserver in contrib. Dbbalancer seems to be more focussed on balancing access and not replication, but can do this too. Michael -- Michael Meskes Michael@Fam-Meskes.De Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
On Tue, 28 May 2002, Michael Meskes wrote: > > This is about pgreplication I think. Is the the replication project of > choice for pgsql? IIRC there quite some projects for this topic: > > PostgreSQL replicator > Rserver > Usogres > dbbalancer There's also DBMirror which I submitted to the contrib directory just after the 7.2 release. I got an email last month saying that it had been applied against the 7.3 tree but I don't see it there. Its a trigger based lazy replication system and has all the associated drawbacks but works for master-slave. I've been working on adding selective replication to it and hope to be able to release another version of that in June. > > Michael > > -- Steven Singer ssinger@navtechinc.com Aircraft Performance Systems Phone: 519-747-1170 ext 282 Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR Waterloo, Ontario ARINC: YKFNSCR
Michael Meskes wrote: > On Mon, May 27, 2002 at 05:12:33PM -0400, Bruce Momjian wrote: > > Last I talked to Darren, the replication code was modified to merge into > > our 7.2 tree. There are still pieces missing so it will not be > > functional when applied. It is remotely possible there could be > > master-slave in 7.3, but I doubt it. > > This is about pgreplication I think. Is the the replication project of > choice for pgsql? IIRC there quite some projects for this topic: > > PostgreSQL replicator > Rserver > Usogres > dbbalancer > > What about these? We seem to have some proof-of-concept code of rserver > in contrib. Dbbalancer seems to be more focussed on balancing access and > not replication, but can do this too. rserver only does single-master, while most people want multi-master. Usogres is more of a load balancer/replication, where the query is sent to both servers. Not sure about the others. The only multi-master solution proposed is pgreplication. I think there is a PDF on that web site that describes the various replication options. I should probably write up a little replication FAQ. Jan is doing a replication talk at O'Reilly in July and hopefully we can get a PDF of that. pgreplication is not good for nodes over slow links or nodes that are intermittently connected, so it is not going to solve all cases either. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
...
> rserver only does single-master, while most people want multi-master.
As you probably know, rserv is not limited to only a single instance of
a single master. Many replication problems can be described as a "single
source" problem (or should be described as such; moving to a fully
distributed database brings a host of other issues). So any problem
which can be decomposed to having single sources of subsets of
information can be handled with this system.
The contrib/rserv code has received no contributions from the community
beyond our original submission, which of course pushes all of the
development and recurring costs back onto PostgreSQL Inc and their
clients. We have been very low-key (imho) in representing this solution
to the developer community, but it should be considered for applications
matching its capabilities. Full transactional integrity across primary
and secondary servers is not easy to come by and not offered by most
other solutions. fwiw we have demonstrated well over 2000 updates per
second flowing through rserv systems.
- Thomas
Agreed. It would be nice to see both a single-master and multi-master server included in our main tree and a clear description of when to use each. The confusion over the various replication solutions and their strengths/weaknesses is a major problem. I always felt a clearer README for rserv would help greatly. We do get lots of questions about how to get it working. README.rserv goes over the major 'toolset' items and describes a demo, but that is it. (I don't even know what the 'toolset' items are or how to access them, at least from reading the README.) I thought of doing the README improvements myself, but because I didn't write it, I left it alone. --------------------------------------------------------------------------- Thomas Lockhart wrote: > ... > > rserver only does single-master, while most people want multi-master. > > As you probably know, rserv is not limited to only a single instance of > a single master. Many replication problems can be described as a "single > source" problem (or should be described as such; moving to a fully > distributed database brings a host of other issues). So any problem > which can be decomposed to having single sources of subsets of > information can be handled with this system. > > The contrib/rserv code has received no contributions from the community > beyond our original submission, which of course pushes all of the > development and recurring costs back onto PostgreSQL Inc and their > clients. We have been very low-key (imho) in representing this solution > to the developer community, but it should be considered for applications > matching its capabilities. Full transactional integrity across primary > and secondary servers is not easy to come by and not offered by most > other solutions. fwiw we have demonstrated well over 2000 updates per > second flowing through rserv systems. > > - Thomas > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, May 28, 2002 at 06:08:21PM -0700, Thomas Lockhart wrote: > clients. We have been very low-key (imho) in representing this solution > to the developer community, but it should be considered for applications > matching its capabilities. I should like to emphasise that I have no desire to run down rserv -- I think it's pretty good, and I'm more than happy with its performance. That I'm now facing a feature-lust argument for ORAC is a political, and not technical problem. > Full transactional integrity across primary > and secondary servers is not easy to come by and not offered by most > other solutions. Exactly, plus there appears to be a big price to be paid for that full integrity. A -- ---- Andrew Sullivan 87 Mowat Avenue Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M6K 3E3 +1 416 646 3304 x110