Subject | Re: [Firebird-Architect] Firebird improvement suggestion |
---|---|
Author | Milan Babuskov |
Post date | 2005-06-21T22:38:41Z |
t_j_haynes wrote:
and events. You can have replicator sitting in background (on main
server) and waiting for event, when event fires, it would just read from
transaction_log table (filled by triggers) do a query with WHERE clause
using the PK, and insert/update/delete that record in other database.
It is very good approach. If network gets down, replicator can build a
list of events, and when connection is back online it can update the
other database. Since it is only using PKs it is not performance
intensive at all. It is somewhat invasive on database structure but if
proper naming is used for all triggers, then it is probably not an issue.
Now, the thing is: I don't know if such replicator exists. I'm even
considering to make one myself, but why waste time if there is something
already there. Do anyone know about such replicator?
--
Milan Babuskov
http://fbexport.sourceforge.net
http://www.flamerobin.org
> There are generic database replication tools. These tend to work byThere is a third approach, similar to what you wrote here: use triggers
> polling and comparing tables. This is quite performance intensive,
> especially if the replica is to be kept reasonably up to date.
>
> There is also the approach of putting triggers on all tables, then
> using a UDF to write details to another machine, then replaying the
> changes. This is rather invasive on the database structure and hard
> to keep up to date.
and events. You can have replicator sitting in background (on main
server) and waiting for event, when event fires, it would just read from
transaction_log table (filled by triggers) do a query with WHERE clause
using the PK, and insert/update/delete that record in other database.
It is very good approach. If network gets down, replicator can build a
list of events, and when connection is back online it can update the
other database. Since it is only using PKs it is not performance
intensive at all. It is somewhat invasive on database structure but if
proper naming is used for all triggers, then it is probably not an issue.
Now, the thing is: I don't know if such replicator exists. I'm even
considering to make one myself, but why waste time if there is something
already there. Do anyone know about such replicator?
--
Milan Babuskov
http://fbexport.sourceforge.net
http://www.flamerobin.org