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(at)navtechinc(dot)com
Aircraft Performance Systems Phone: 519-747-1170 ext 282
Navtech Systems Support Inc. AFTN: CYYZXNSX SITA: YYZNSCR
Waterloo, Ontario ARINC: YKFNSCR