Subject Re: [ib-support] Failover Strategies
Author John Peterson
Thanks Arthur,
Hmmm....The possibility of 1/2 the users on a different server is not one I
had thought about!!
Hourly backups would be unacceptable in my application....1 hours lost data
= stopped production line for an hour.
My application is fairly simple. It has a data feed to the 2 servers. These
feeds do most of the DB writes. The clients are pretty much read-only,
except for setting a few flags as they process the contents of the tables.
The biggest problem I have is knowing why no data is coming. Is it the
server/network dead, is it no new data from the feed etc. Dead networks are
worst, since the TCP/IP connection takes forever to give up is the server
side is simply disconnected.

Also my customer has little technical knowhow, so manual failover is
impractical (I want to be there less, rather than more :) )

IBReplicator may do the job of keeping the users changes
looking at this, though it's operation is not too intuitive.

I will persue the Stored Procedure with "ping" it will definitely
tell me if the IB server is alive, at low IB overhead.

Starting to see why Redundant systems are so expensive!!!

> I have an installation that I do hourly backups to a different server. It
> works like this:
> Two w2k servers, each hour the primary server do a backup, compress the
> data, ftp it to the secondary server, the secondary one decompress the
> and restore it. This way I have the possibility to work with the secondary
> server if something went wrong with the first one, and maximum disaster <
> hour. (The BD is not to big - 250Mb - and the network is fast, so
> runs well). Of course some users 'feel' the hourly backup (it takes 5 to 7
> minutes), but they survive very well.
> (I have some facilities here - some 'power users' that need to get long
> reports of statistical data of last month, for example, use the secondary
> server)
> I thougth about the kind of situation you talked, but I have a problem
> doing that automatically: if the problem was network related, could be
> cases that some of the workstations could ping the server and others not.
> (This installation have 4 buildings connect by 3 switches, and an outside
> company that conects to the DB via internet. The primary and secondary
> server are in different buildings, for space and security reasons. 40
> use to be online at the same time in all buildings).
> I give up the idea to 'ping' the server if something fails, and now that
> process is manual: when something gets wrong with the primary server,
> someone there disconnects the power from the primary server, and set the
> address of the secondary to be equal to the primary. This operation take
> longer than 5 minutes. That's the only way I found to make shure that
> everybody is working on the same server at the same time.
> I'm really interest in this subject. Someone else as other ideas to this
> kind of situation?
> ----- Original Message -----
> From: "John Peterson" <jcp@...>
> To: <>
> Sent: Friday, December 14, 2001 12:26 AM
> Subject: [ib-support] Failover Strategies
> > I wish to have an application fail over automatically to a backup server
> in the event that the primary fails (power fail, IB failing, LAN failing
> etc.), specifically to know if the primary is operating.
> >
> > The application uses IBO, and DML Caching, allowing the server to "push"
> table changes out to the clients without the client continually polling
> server.
> >
> > I would be interested to hear how people implement a low cost "ping"
> request to the server. A simple query, or call to a SP may be best, since
> it would test all required systems.
> >
> > TIA
> > John
> To unsubscribe from this group, send an email to:
> Your use of Yahoo! Groups is subject to