Re: Replication direction - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Replication direction
Date
Msg-id 200202221720.g1MHKTf20720@candle.pha.pa.us
Whole thread Raw
In response to Re: Replication direction  (Ned Wolpert <ned.wolpert@knowledgenet.com>)
Responses Re: Replication direction
Re: Replication direction
List pgsql-hackers
Ned Wolpert wrote:
> One thought I had about replication is base it off of the WAL files. As
> they are created, they can be forward into other servers (both on a LAN
> and WAN environment) and imported to mirror the originating database. 
> (As opposed to having triggers that force writes into replicated servers
> on updates, inserts and deletes)

OK, let me chime in here and give my observations, then I will address
the WAL issue.  First, in all the discussions I have heard, the final
replication solution needs to be:
multi-mastergood performancelow maintenance (no conflict resolution rules)

Now, at the URL I mentioned, there are 5+ other pgsql replication
solutions listed:
http://gborg.postgresql.org/genpage?replication_research

However, I don't think any of these meet this criteria, particularly
because they are not integrated into the backend code.  That doesn't
mean they aren't valuable, but that they don't represent a final
solution for pgsql replication.

As far as I know, the only working project that will meet these needs is
the one at that URL based on Postgres-R.  What impressed me about it was
that it did not use two-phase commit, nor conflict resolution rules, but
rather used a queue of changes that gets broadcast to all the servers in
the replication cluster.  This seems to allow high throughput with low
maintenance.

The actual direction of the project was decided by researching all the
current solutions and educational research to find the strengths and
weaknesses of each one.

As far as WAL, it currently has the tid's in the WAL file which will not
match other servers unless those servers are read-only.  It is tempting
to think that WAL or some other existing mechanism will allow us to do
replication cheaply, but it is my understanding that the interactions of
multiple write server is quite complicated and requires an amount of
overhead mechanism that is similar to our current transaction mechanisms
that allow multiple people to modify the same table.

People know I am all for the quick solution if it fits into our existing
code, but I am afraid replication is one of those items that has to be
designed from the ground up on a foundation that is backed by research
and experts in the field.  I think this replication project has the
potential to give us a replication capability that is better than
the commercial offering of other databases.

--  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
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Replication direction
Next
From: bpalmer
Date:
Subject: Re: Replication direction