Beyond MSCS

3 4

We've examined the basics of MSCS and how SQL Server works within that architecture. We've also seen how SQL Server can survive some types of catastrophic hardware and software failures and be back up and running transactions in a short time. To achieve this degree of fault tolerance, you must not only enable MSCS but also take other measures. Two important steps are to perform regular and effective backups and to prepare a disaster recovery plan. The procedures for backing up your system and preparing a disaster recovery plan are described in detail in Chapters 32 and 33. Clustering servers and creating RAID storage are not alternatives to performing backups. In many cases, neither of these technologies can help you if your system crashes and you have not performed a backup. These situations can include the following types of failures:

• Hardware failures In rare cases, hardware failures can corrupt data. If the primary system experiences a hardware failure that corrupts the database, the secondary server will fail over to a corrupted database.
• Software failures Regardless of how well software has been developed and tested, occasional bugs can sneak in. If one of these rare software bugs corrupts the database, failover to that database will be of no avail. RAID technology will simply offer a fault-tolerant copy of corrupted data.
• Human error Users commonly delete their data by mistake. Neither clustering technology nor RAID will solve this problem.

In Chapters 32 and 33, you'll learn more about planning for a disaster and enabling your system to survive one. The preceding examples simply illustrate the fact that clusters and failover serve specific purposes and are only two weapons in the battle to provide constant data access and data integrity.