Replication status

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, Pennsylvania 19026

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, Pennsylvania 19026

...

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, Pennsylvania 19026

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