711
Chapter 27: Database Mirroring
27
mirror role but the database mirroring session is suspended. To resume the database mirror-
ing session, follow the steps discussed earlier in the chapter.
After any type of failover, clients must reconnect to the new principal database. If your
applications use Microsoft ADO.NET or SQL Native Client to connect to a database, then if
a database mirroring failover occurs, the applications can automatically redirect the cli-
ents to the current principal database. You must specify the initial principal server and
database and failover partner server in the connection string. The failover partner in the
connection string is used as an alternative server name if the connection to the initial
principal server fails. If your applications do not use Microsoft ADO.NET or SQL Native
Client automatic redirection, you need to use other methods such as using network load
balancing (NLB), Domain Name System (DNS) alias, or custom code that can enable your
application to failover.
After the role switching process is completed, verify that any database objects such as log-
ins, jobs, maintenance plans, SSIS packages, and linked servers that reside outside the mir-
ror database are created on the mirror server. For example, if the logins are not created on
the mirror server, the users cannot connect, and you still have a server down situation.
Best Practice
Thoroughly execute the role-switching steps and document them prior to needing to failover to the
mirror server. Failure to do this can signifi cantly increase downtime and complexity when you actually
need to failover to the mirror server.
High Availability/AlwaysOn
AlwaysOn Availability Groups are the next evolution of mirroring technologies in SQL
Server. As reviewed in the fi rst half of this chapter, mirroring allows you to mirror only on
a per-database (1:1 ratio). With SQL Server 2012, you can defi ne multiple databases together
in a logical container called an availability group that enables the databases to fail over
together as a single unit.
In addition to grouping databases together, you now get up to four readable secondary cop-
ies of your database. This gives you the fl exibility to offl oad reporting from your primary
transactional databases or even take backups from your secondaries! AlwaysOn Availability
Groups offers the following benefi ts:
■ Multiple secondary replicas (one primary and up to four secondary replicas).
■ (^) Readable secondary replicas.
■ Flexible failover policies, for more granular control over conditions that cause auto-
matic failovers for an availability group.
c27.indd 711c27.indd 711 7/31/2012 9:50:30 AM7/31/2012 9:50:30 AM
http://www.it-ebooks.info