Replication Vs Mirroring

I have two Unix servers with SCO 5.0.5 and IDS 7.31. Instead of installing Data Replication can I set up mirroring? What I mean is that I will have two identical servers and their disks will be replicated. What conserns me is how Informix will behave under this configuration. Thanks, Vasilis

Hi, according to the 'Administrator's Guide' it is not recommended to use mirroring over ethernet. Greets, Andy

Vasilis Econmonides wrote in message <3A892156.38432ACC@ctl.com.cy>... >I have two Unix servers with SCO 5.0.5 and IDS 7.31. Instead of >installing Data Replication >can I set up mirroring? What I mean is that I will have two identical >servers and their disks >will be replicated. What conserns me is how Informix will behave under >this configuration. > Potentially very badly. Here's a reply I posted several weeks ago. There was a few follow-up postings, but I stand by this theory until proven wrong. The follow-up postings concerned the reliability and sequencing of network and cooked file writes. The thread was called "chunk transplant" if you'd like to track down the followups - especially if you have some counter-arguments of your own. Before you start reading, what you are implying relies on using cooked files instead of raw spaces; that's why there's mention of cooked files. BEGIN BLURB: Robert Carts wrote in message <9422kf$k08$1@knight.vf.lmco.com>... >We have been investigating ways to keep data current on a local and >identical backup server. We are aware of IER and HDR. My boss suggested >that we keep a mirrored chunk on a cross mounted drive that resides on the >backup server. Then in the event of a failure of the primary server, bring >the backup server online using the primary servers chunk. I skeptically >attempted this and it worked! > <SNIP> > >Question: Under what conditions would this not work (within the conditions >above) ? I either need to demonstrate why not to use the technique or make >it work reliably? > >Thanks, Bob Carts *) Performance will be much worse just from using cooked files. My experience shows typically 10 times worse. *) Cooked files are intrinsically unreliable because the engine sometimes needs to guarantee that pages are physically written in special sequences, and you just can't get that reliability when the O/S uses buffering and picks it's own sequence of flushes to disk. *) Performance will be even worse than that since one of the mirror pairs will be at the end of a network connection and NFS. *) If the network has a hiccup or the machine with the mirrors goes offline, then the mirrors will be marked down on the first attempt to access them, and it will perform a full update of the mirror chunks once the connection is reestablished. This will cause mass traffic on the network and hit both machines really hard. *) If the original machine goes down, and you attempt to bring up an instance on the mirror machine, then there is a really strong chance that the so-called mirror instance will be in an inconstent state, due to the unpredictability of the sequencing of the network writes and the UNIX writes to cooked files. In a sense, for reliability, a remote cooked file is as bad as a local cooked file only much worse. If the physical data is inconsistent then the results will be anything from complete failure to bring up the mirror instance, to grubby damaged data (which is probably worse because you will be tempted to imagine that it's clean and reliable data) SUMMARY: don't do it. If you want fallback to another machine, then: *) use the replication offerings, or *) improve the hardware redundancy within the source machine: mirrored disks, multiple disk controllers, duplicate power supplies, hot-swappable disks and even controllers and power supplies - whatever it takes to reach the level of reliability you require for 24*7*365 uptime. *) If you are not concerned with 100% uptime, but just want the convenience of a mirror machine, consider setting up identical machines (including partitioning layouts) and identical config files etc. Then, you could archive the main machine (as you should) and restore to the mirror machine, which would give you the luxury of having a test of the quality of your archives. By a strange coincidence, our development machine blew up it's power supply last night, and one of our chunks got scribbled in the process because a big mass-compile was running at the time. We haven't mirrored the development databases, because we don't see the need. I'm still very happy with that decision after today's experience - we had to restore from an archive tape and now we're back in business. Total time down: 15 minutes to screw in a new power supply, plus the time to restore the archive; typically 130% of the time archives take to write in my experience. This is the bread and butter of maintaining the security of your databases. Cute or interesting ideas will inevitably end in tears.