SQL Server 2008 Availability

Backup to Disk

The first thing to look at is the simplest technology--backup. In the Enterprise edition of SQL Server 2008, Backup has a new feature, which is backup compression. So how does backup compression help with high availability?

Then mention the very popular backup solution in the industry today-backup-to-disk solution, with many similar names: Online backup, virtual tape library, and so on. These programs are actually based on the idea of backing up data to a fast online disk device so that you can take advantage of the high speed IO and high-speed retrieval capabilities of the disk. However, the high cost of disk is often the main reason for this enterprise to stop before this solution, and now the backup compression in SQL Server 2008 Enterprise Edition can greatly reduce the file size after backup, so the disk-based backup solution looks more competitive.

The biggest benefit of disk-based backup is the ability to use disk high-speed IO for fast restores. This reduces the time that the database service is offline, while also reducing the impact of the maintenance operation on the application of the database backup.

Database mirroring Failover Cluster

The failover cluster, log shipping, or disk-based backup that we described above is emerging as a single technology, and in a real, medium and large enterprise environment, we usually have some combination of highly available technologies in order to ensure continuous data application online. By mixing different usability technologies, we will be able to shorten the length of the harvest.

such as database mirroring technology.

Although database mirroring resolves a single point of failure threat and relies on special hardware for failover set shared storage, the biggest problem with database mirroring is the short failover path. For large and medium-sized enterprises, only two node failover paths are somewhat inadequate. Therefore, the problem that the database mirroring failover path is too short can be solved by adding a failover cluster as the mirror node of the database mirroring.

The above solution when the principal server fails, database mirroring starts the mirroring node, and because the mirror node is assumed by a failover cluster, a node in the mirror node fails with a fallback node, so there is a fallback node to assume.

In fact, there are pros and cons to failover clustering and database mirroring, so the solution to the two technologies is not just the one above, but the following is a schematic diagram of a different solution:

Careful readers may find that two of scenarios do not have a witness node, which means that switching from a primary cluster to a mirrored cluster requires manual completion. So why is there no witness node in this solution?

Because both database mirroring and failover clusters have an automatic failover feature, if the automatic switching of both technologies takes effect, then two nodes will attempt to take effect after the active node of the main cluster is invalidated--the backup node of the main cluster and the active node of the mirrored cluster, then there is only one result. Database mirroring session failed.

Remote Failover Cluster

For some trans-regional and even trans-continental conglomerates, the problem of site failure is gradually coming into the minds of it executives and DBAs.