Bruce Momjian wrote: > OK, the first thing is that there isn't any one replication solution > that will behave optimally in all situations.
Right > Now, let me describe Postgres-R and then the other replication > solutions. Postgres-R is multi-master, meaning you can send SELECT and > UPDATE/DELETE queries to any of the servers in the cluster, and get the > same result. It is also synchronous, meaning it doesn't update the > local copy until it is sure the other nodes agree to the change. It > allows failover, because if one node goes down, the others keep going. Wrong It is asynchronous without the need of 2 phase commit. It is group communication based and requires the group communication system to guarantee total order. The tricky part is, that the local transaction must be on hold until the own commit message comes back without a prior lock conflict by a replication transaction. If such a lock confict occurs, the replication transaction wins and the local transaction rolls back. > > Now, let me contrast: > > rserv and dbmirror do master/slave. There is no mechanism to allow you > to do updates on the slave, and have them propagate to the master. You > can, however, send SELECT queries to the slave, and in fact that's how > usogres does load balancing. But you cannot use the result of such a SELECT to update anything. So you can only phase out complete read only transaction to the slaves. Requires support from the application since the load balancing system cannot know automatically what will be a read only transaction and what not. > > Two-phase commit is probably the most popular commercial replication > solution. While it works for multi-master, it suffers from poor > performance and doesn't handle cases where one node disappears very > well. > > Another replication need is for asynchronous replication, most > traditionally for traveling salesmen who need to update their databases > periodically. The only solution I know for that is PeerDirect's > PostgreSQL commercial offering at http://www.peerdirect.com. It is > possible PITR may help with this, but we need to handle propagating > changes made by the salesmen back up into the server, and to do that, we > will need a mechanism to handle conflicts that occur when two people > update the same records. This is always a problem for asynchronous > replication. PITR doesn't help here at all, since PeerDirect's replication is trigger and control table based. What makes our replication system unique is that it works bidirectional in a heterogenious world. > I will describe the use of 'spread' and the Postgres-R internal issues > in my next email. The last time i was playing with spread (that was at Great Bridge in Norfolk), it was IMHO useless (for Postgres-R) because it sometimes dropped messages when the network load got too high. This occured without any indication, no error, nothing. This is not exactly what I understand as total order. I hope they have made some substantial progress on that. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] # ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
