Re: Replication

DBMirror doesn't use snapshot's instead it records a log of transactions 
that are committed to the database in a pair of tables.  
In the case of an INSERT this is the row that is being added.
In the case of a delete the primary key of the row being deleted.

And in the case of an UPDATE, the primary key before the update along with 
all of the data the row should have after an update.

Then for each slave database a perl script walks though the transactions 
that are pending for that host and reconstructs SQL to send the row edits 
to that host.  A record of the fact that transaction Y has been sent to 
host X is also kept.

When transaction X has been sent to all of the hosts that are in the 
system it is then deleted from the Pending tables.

I suspect that all of the information I'm storing in the Pending tables is 
also being stored by Postgres in its log but I haven't investigated how 
the information could be extracted(or how long it is kept for).  That 
would  reduce the extra storage overhead that the replication system 
imposes.

As I remember(Its been a while since I've looked at it) RServ uses OID's 
in its tables to point to the data that needs to be replicated.  We tried 
a similar approach but found difficulties with doing partial updates.






On Mon, 4 Feb 2002, mlw wrote:

> I did a similar thing. I took the rserv trigger "as is," but rewrote the
> replication support code. What I eventually did was write a "snapshot daemon"
> which created snapshot files. Then a "slave daemon" which would check the last
> snapshot applied and apply all the snapshots, in order, as needed. One would
> run one of these daemons per slave server.





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