On February 8, 2005 09:58 pm, David Johnson wrote:
>
> Regarding 24x7 - A few years back, a certain shop announced it had full
> 24x7 capability with auto-failover to a backup hot-site. It was tested
> during peak production hours and no one noticed that the switchover had
> occurred. Exactly one week after the announcement, the DASD unit with
> the only copy of the failover program blew up (literally), and there was
> no manual switch over mechanism. It took a week to get that company
> back on line again. :o)

That is funny, we are forced to have so much redundancy, we have machines that
are retired before they ever perform any actual work.

Our Pop at 151 Front Street, Toronto, is made redundant by another pop in
Ottawa and a third pop in Montreal. They are connected by an OC48 dedicated
to lan redundancy.
We also have a smart alec who randomly goes to our pops and pulls power to
test our failover and response times. That once had the CEO drop everything
at a dinner party to drive a line card from Ottawa to Montreal at 9pm.
The smart alec gets paid to do it........we are just suckers for punishment.

Back to some design issues, the database should be built to allow load
balancing. This not only allows offline use of the datastructures (salesmen
on the road), the same reconsiliation procedures to reintegrate offline work
can be used continuously to support multiple servers acting as a single
server.

This also allows fail over situations where the clients are designed to
connect to a separite database if thier primary connection fails. They then
track the latest updates from the replication bot and if neccessary, replay
any transaction out of their current session log to bring the secondary
database up to speed.

Scalability again comes back to the design, if you build your database to
handle live replication, you can set up alot of smaller machines and have
them load balance for your application.

best regards

Dalton