Actually, I wouldn't design it that way. I don't like having multiple
failovers triggered by a single failover, but it does accomplish a minimal
downtime along with multiple failover options.
As long as you have coded applications to take advantage of the transparent
client redirect capability, the failover to the mirror is actually a better
option that failover in a cluster since the cache on the mirror has already
been warmed up. If your applications can not take advantage of the
transparent client redirect, then it will be much longer to failover
applications since that needs to be done manually. With mirroring, you also
have to pay attention to logins, jobs, and other items outside of a single
database. However, if you factor for all of that, your applications will
have less downtime with Database Mirroring and the 2nd node in the cluster
becomes your secondary failover option.
The more I work with it and the more production systems that I see it
running on, the more I'm using Database Mirroring as a primary availability
option due to the simplicity, minimal downtime, and the fact that it doesn't
require any specialized knowledge to work with or troubleshoot.
--
Mike
http://www.solidqualitylearning.com Disclaimer: This communication is an original work and represents my sole
views on the subject. It does not represent the views of any other person
or entity either by inference or direct reference.
[quoted text, click to view] "Tom Moreau" <tom@dont.spam.me.cips.ca> wrote in message
news:%23Vuv6UKhGHA.1856@TK2MSFTNGP03.phx.gbl...
> You can use a cluster in conjunction with DB mirroring. Since a mirror
> failover is faster than a cluster failover, then the Mirror will become
> the
> Principal when the cluster fails over (if you have a Witness and set up
> for
> High Availability). Failback is not automatic. Consider using manual
> failover for DB mirroring. This way, the cluster fails over from one node
> to another. You can then manually failover to the mirror for disaster
> recovery or for planned maintenance on the cluster.
>
> You don't need a separate NIC for mirroring.
>
> --
> Tom
>
> ----------------------------------------------------
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
>
> "Tim Murray" <tim@nexgen-online.com> wrote in message
> news:Ocul6yFhGHA.1520@TK2MSFTNGP03.phx.gbl...
> OK hopefully an easy question for the experts.
>
> We are currently trying to design/test implement an SQL Solution to use DB
> Mirroring with SQL 2005 Ent.
>
> We have successfully built an SQL Cluster with 05' Ent SP1 x 64 on with
> Windows 2k3 Ent 64bit MSCS. We also have an additional Server with SQL
> 2005
> Ent x64 to be a mirror. Finally we a witness server built with SQL
> Express.
>
> Can we use a clustered server as a Principal and Stand alone server for a
> mirror? I am assuming if we can get this to work the mirror will take
> over
> before the 2nd cluster node. But that is ok with us.
>
> Do we need separate public nic for mirroring? That would be a Cluster
> Resource?
>
>
>
>
>
>
