Subject | Re: [ib-support] Failover Strategies |
---|---|
Author | Artur Anjos |
Post date | 2001-12-14T00:59:11Z |
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 data
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 < 1
hour. (The BD is not to big - 250Mb - and the network is fast, so everything
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 some
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 users
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 IP
address of the secondary to be equal to the primary. This operation take no
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?
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 data
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 < 1
hour. (The BD is not to big - 250Mb - and the network is fast, so everything
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 some
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 users
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 IP
address of the secondary to be equal to the primary. This operation take no
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: <ib-support@yahoogroups.com>
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 the
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