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: