Database Mirroring vs Failover Clustering
Database mirroring is most often compared with failover clustering since to the untrained ear, as they sound similar. However, they are fundamentally different. In some of its early marketing material for SQL Server 2005 (the first version with database mirroring), Microsoft gave the impression that it was positioning database mirroring to replace failover clustering. Database mirroring is by no means a cluster killer, though—at least how it is currently implemented. Architecturally, both have the concept of quorum. Endpoints in database mirroring are similar to the cluster’s private network. Both require that the servers participating are using the same edition of SQL Server. Both support automatic and manual failover options. By default, failover clustering is designed to take advantage of an automatic failover, whereas database mirroring depends on which mode is implemented. Depending on how the application is coded, whether you are using failover clustering or database mirroring, it may or may not force you to reconnect after an automatic failover. Both technologies provide ways to minimize impact on the end users, but it is up to the developer to implement them.
Both give you excellent availability, but their main difference is that failover clustering protects your entire instance, while database mirroring protects a single database. This is a huge difference. It means that in a failover for a clustered instance, you will have to worry about reconnecting to the instance, but everything will still be there. With database mirroring, logins will need to be added and synchronized, and anything that resides outside of the database that is not captured as a transaction (such as jobs, maintenance plans, etc.) will need to be created on the mirror. However, the storage in failover clustering is a single point of failure, whereas with database mirroring, you have two separate copies of a particular database vps hosting. Another aspect that is easier with database mirroring is spanning distance. With failover clustering, you need a specialized, geographically dispersed cluster solution that most likely has some sort of physical limitation (e.g., fiber is only rated at certain distances) that you cannot avoid. Database mirroring involves two separate installations that can reside on any supported hardware (clustered or not), and is not bound by distance, but by the limitations of your network bandwidth and the speed of applying the transactions. The time it takes to get back up and running after a problem is different with database mirroring and failover clustering. Failover clustering is generally measured in minutes by the time user databases are available, and database mirroring could be seconds. After the database has failed over to the mirror, you still may have to perform other steps such as creating SQL Server Agent jobs or synchronizing logins to ensure that it is a fully working copy of the original, so there may be a net savings of zero time.
Failover clustering has no limitations in terms of what features it supports with SQL Server 2008, whereas database mirroring, as an example, supports different modes on different editions of SQL Server and does not support the filestream data type. If you have an application or a related set of applications that use multiple databases, those are generally more suited to failover clustering, since they can be configured in the same instance and all fail over at once, creating a consistent failover point for each database. Last but not least, with failover clustering, you have a definite single point of failure in your disk subsystem. Configuring your disks with some sort of RAID gives you some redundancy, but if you are not deploying a geographically dispersed failover cluster, your disks are all part of the same set of enclosures in one data center and become your single point of failure. Database mirroring’s architecture enables redundancy across distance to another data center.
Processing your request, Please wait....
