Note that you must store the database snapshots on a clustered resource. Storing
them on a local cluster node will invalidate the snapshots in the event of a failover. Database
snapshots as implemented by the initial release of SQL Server 2005 have a number
of limitations, but as long as you store them on a clustered disk resource, clustering won??™t
increase those limitations.
Clustering and Database Mirroring
Whenever I??™m presenting at a conference or teaching, people often ask if they can combine
clustering and database mirroring. The hardware protection of a cluster and the
real-time duplication of data off-site is an attractive combination. Cluster failover is
quick, as is database mirroring. You also avoid the complicated failover and failback
procedures required by log shipping.
However, the combination of clustering and mirroring comes with some complications.
Controlling which feature is first to fail over can be difficult. Ideally, if you have a
hardware issue, you??™ll want clustering to fail over to a secondary physical node rather
than have database mirroring fail over to a remote location.
Pages:
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507