Re: Replication direction

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Ned Wolpert <ned(dot)wolpert(at)knowledgenet(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Replication direction
Date: 2002-02-22 17:20:29
Message-ID: 200202221720.g1MHKTf20720@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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-master
good performance
low 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(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-02-22 17:22:12 Re: Replication direction
Previous Message Marc Munro 2002-02-22 17:03:57 Re: point in time recovery and moving datafiles online