Subject | Re: [ib-support] keeping current "standby" data |
---|---|
Author | Jason Chapman (JAC2) |
Post date | 2002-08-01T16:50:13Z |
Sounds to me like you are after replication. I support a site that have
multiple "report" and near live servers running as backups to the main
server, we use role your own replication.
The main issue you will have past replication itself (we used the variety
that just puts the PK, tablename and action (insert / update / delete) into
a replication table, is that all DB's have to have the same structure and as
such when you want to promote a backup to a live you need to:
1) Report on how up to date you believe the DB to be (on this system it
ranges from 0s to 60 minutes depending on load etc, but 60 minutes is
usually after a massive single transaction update).
2) Be able to synchronise the generators
3) Enable the replication triggers (I am wetting myself about the generic,
non table bound triggers!).
Doug Chamberlain (sorry for the spelling) wrote a wonderful short brain dump
on issues surrounding robot processes a couple of years ago.
I wouldn't be surprised if shadowing bit the dust sooner or later as a FB
feature, I certainly wouldn't vote to keep it.
HIH
BTW I was on a new client site today and got a report that was taking 8
hours down to < 1 minute, don't you wish every day was like this?
Jason Chapman
JAC2 Consultancy
Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: When I get round to it....
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088
"Bernahrd Nemec"
multiple "report" and near live servers running as backups to the main
server, we use role your own replication.
The main issue you will have past replication itself (we used the variety
that just puts the PK, tablename and action (insert / update / delete) into
a replication table, is that all DB's have to have the same structure and as
such when you want to promote a backup to a live you need to:
1) Report on how up to date you believe the DB to be (on this system it
ranges from 0s to 60 minutes depending on load etc, but 60 minutes is
usually after a massive single transaction update).
2) Be able to synchronise the generators
3) Enable the replication triggers (I am wetting myself about the generic,
non table bound triggers!).
Doug Chamberlain (sorry for the spelling) wrote a wonderful short brain dump
on issues surrounding robot processes a couple of years ago.
I wouldn't be surprised if shadowing bit the dust sooner or later as a FB
feature, I certainly wouldn't vote to keep it.
HIH
BTW I was on a new client site today and got a report that was taking 8
hours down to < 1 minute, don't you wish every day was like this?
Jason Chapman
JAC2 Consultancy
Training - Development - Consultancy
Delphi, InterBase, Firebird, OOAD, Development lifecycle assistance,
Troubleshooting projects, QA.....
www: When I get round to it....
Mob: (+44) 07966 211 959 (preferred)
Tel: (+44) 01928 751088
"Bernahrd Nemec"
> Hello"lead"
>
> I want to set up two (or more) database server machines redundantly,
> supporting a "failover" scenario where a "standby" machine takes over
> operation from the "lead" machine as soon as the "lead" dies. This can be
> done for example with "HA Linux" (www.linux-ha.org).
>
> Now the obvious problem with the database is that I need to keep current a
> data file on the standby, i. e., somehow send all updates done to the
> database also to the standby database.only
>
> It would also sufficient to have a current .gbk file on the standby, and
> restore it to a .gdb in the failover case. But, of course, I want to avoidinsert,
> sending the whole data file (or a backup) to the standby periodically. I'm
> looking for a solution that just only sends the updates.
>
> For example, it would be useful if a UDF could be passed the full SQL
> update, or delete commands, triggered whenever one of these is issued.Such a
> UDF could just connect to the standby machine and apply the same command
> there.
>
> Thank you for any input!
> Bernhard
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>