Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The case:

  • An industrial IT system, controlling and storing data on two production lines
  • There is one server per production line. Each server runs the automation objects for that production line. Each server has a local SQL server database that stores data for that production line.
  • The automation software has built-in redundancy. A server failure on one production line's server will cause the automation objects to run on the other server instead.

An imagined scenario: The disk controller on production line 1's server fails. Currently, the following will happen:

  • The automation objects will start running on production line 2's server instead.
  • But when the automation objects start doing data access to server 1, they will of course fail (since the disk controller is non-functional).

So we have discussed options. A colleague has suggested the following:

  • Replicate the server 1 database on server 2. And vice versa.
  • Set up the data access with localhost connection strings.
  • So when the automation objects start running on the other server, their data access will go to the database on the server they are running on.

I do not have experience with replication. Is replication a viable solution to the problem described above? Important things to remember when setting up replication? Other suggestions?

share|improve this question
up vote 3 down vote accepted

If you're using SQL2005 or 2008 you could consider synchronous database mirroring between your two servers, with a third server acting as witness which handles automatic fail-over. This is known as "High safety without automatic fail-over"

Or if you can use shared storage between your servers you could consider an active/passive windows cluster.

share|improve this answer
  1. how about a centralized SQL backend for all those local DBs?
  2. virtualize the controlling OS with everything in it, so if a physical server fails, the VM is started on another server.
  3. leave everything as is, but equip the servers with FT features,, i.e. dual PSUs, RAID10 over two controllers, two UPS units powering redundant powergrids etc.
share|improve this answer
I have also suggested one central SQL server (that is what you mean by 1., right?). Others on the project feel that creating a single point of failure would not be acceptable. – codeape Sep 22 '09 at 12:11
that's exactly what I meant. and a SQL backend can be an SQL cluster with a few nodes and a redundant storage, backed up by both tape and a snapshot scheme. it all depends on the budget really – dyasny Sep 22 '09 at 13:08

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.