Configuring Database Mirroring
Similar to when you use log shipping, you must
perform a full database backup on the primary, copy the backup to the
mirrored server instance, and restore the database using the WITH NO RECOVERY option within the BACKUP DATABASE
statement. Once the database is restored to the mirrored server, you
can configure mirroring for the database by selecting Mirror from the
Tasks menu or the specific database node in Object Explorer. For this
example, we will mirror the UsedCars database from the default instance
on ROB-DENALI-1 to the named instance, ROB-DENALI-1\INST2. On our test machine, we created a folder C:\backup\dm to hold the database backup. Next, we connected to the default instance, ROB-DENALI-1, and issued the following statement using the Query Editor in SSMS:
BACKUP DATABASE UsedCars FROM DISK='c:\backup\dm\UsedCars.bak'
If, at this point, the SQL Server instance we
are mirroring to was on a remote server, we would copy the backup file
to that server. In this example, the SQL Server named instance resides
on the same physical machine, so we do not need to copy the backup file.
Connect to the INST2 named instance, ROB-DENALI-1\INST2,
using SSMS and restore the UsedCars database with the following
statement. Before you execute the statement, make sure that the
directory C:\data exists. Create that directory if necessary.
RESTORE DATABASE UsedCars FROM DISK='c:\backup\dm\UsedCars.bak'
WITH MOVE 'UsedCars' TO 'C:\data\UsedCarsInst2.mdf',
MOVE 'UsedCars_log' TO 'C:\data\UsedCarsInst2.ldf',
NORECOVERY;
If you refresh Object Explorer, you can see
that the UsedCars database node is shown as “UsedCars (Restoring . .
.)”. At this point, we can connect back to the default instance and
select Mirror. This will launch the database properties dialog with the
mirroring label preselected. This dialog is shown in Figure 7.
Figure 7. Mirroring panel of the Database Properties dialog
The first thing that needs
to be done is to configure security. Once you’ve done that, the other
sections including the server network address and operating mode will
be enabled and available for editing.
Clicking the Configure Security button will
launch the Configure Database Mirroring Security Wizard. The first page
will ask you if you wish to include a witness server to enable the
synchronous mode with automatic failover. In this example, we will
configure asynchronous mirroring, so a witness is not needed and we
will select No.
The next page in the wizard, shown in Figure 8, will define information about our primary instance such as the TCP/IP listener port that will be used.
Figure 8. Configure Principal Server Instance
The default listener port is 5022 and can be
changed. Database mirroring uses a feature called endpoints within SQL
Server. At a high level, endpoints define an entry point into SQL
Server. An endpoint defines a protocol, such as shared memory, TCP/IP,
or named pipes, and a payload, such a TDS. Once an endpoint is defined,
you can lock down who specifically can access that endpoint. In
database mirroring, an endpoint is created and only the SQL Server
instances involved with the database mirroring
session can connect to it. The endpoint name in the case of this
example mirroring configuration is given a generic name of Mirroring.
This can be changed to something more descriptive.
The next page in the wizard will configure the
mirror server instance. Similar to the way you defined the Principal
Server instance in Figure 8, you will define a listener port on that server instance and provide an endpoint name.
Since database mirroring will define endpoints
on both the principal server and mirror server instance, the wizard
will next ask you for the service accounts for these instances. This
wizard page is shown in Figure 9.
Figure 9. Specifying service accounts wizard page
After setting the accounts, the wizard has
enough information to create the mirror. After completing the wizard,
you will be prompted with a dialog box asking if you wish to start the
mirroring session. If you elect to do so, you will see the dialog
indicated that the mirrors are being synchronized.
At this point, the
database mirroring session should be enabled and running. There is a
database mirroring monitor that is available to see the health of your
mirror. It can be accessed via the Launch Database Mirroring Monitor
context menu command under the Tasks menu of the database container
node in object explorer.
Note
There are a few moving parts to setting up database mirroring. If you
have been following along and run into problems, they are most likely
caused by security settings. You should use a domain account for the
principal and mirror service accounts.
5. AlwaysOn Failover Clustering
SQL Server 2012 introduces a new technology
called AlwaysOn Failover Clustering. Log shipping and database
mirroring work at the database instance level. With those technologies,
you can fail over a specific database and have the other databases
still online in the primary server. One of the biggest differences in
those two technologies versus failover clustering is that failover
clustering is a protection of the SQL Server instance itself. If a
failure occurs in a SQL Server and its clustered, the whole instance
will be failed over. SQL Server leverages Windows Server Failover
Clustering to enable this capability, and the resulting new feature set
is termed AlwaysOn Failover Clustering.
In the clustering world there are active and
passive nodes. Active nodes are servers that have active connections
and are doing work. Passive nodes are not handling any active user
workload. On an active node, the SQL Server service is started, and
there are active user connections. On a passive node, the SQL Server
service is stopped, and the server is waiting for a failover. In a
configuration where there are two servers with one being active and the
other being passive, this is said to be an active/passive
configuration. Upon a failure of the active node, the passive node will
start the SQL Server instance and allow users to make connections. This
is possible since both servers share a common disk. A common disk also
means a single point of failure, so in most clustering designs, the
disk architecture has redundancy and fault tolerance. This shared
storage must be in the form of a storage area network (SAN), iSCSI
targets or both.
The example where we have one active and one
passive is known as a two-node cluster. SQL Server supports as many
cluster nodes as Windows Server supports. In Windows Server 2008, SQL
Server supports up to 16 nodes. Typically, most enterprises have
between two and four nodes in a cluster. When a cluster has more than
two nodes, the remaining nodes are always passive and failed over when
the other passive nodes are not available.
You may be thinking that it would be a waste of
electricity to keep multiple passive nodes running and essentially not
doing any work. This is the case, and some IT departments end up
creating active/active clusters. In this configuration, you may have
server A with databases 1, 2, and 3 fail over to server B and server B
databases 4, 5, and 6 failover to server A. The important thing to note
is that in the event of a failure, servers A and B need to assume the
workload of all the databases, so we need to make sure that the
hardware can support this load.
Typically, in our
scenario, servers A and B are located within the same datacenter. In
geoclustering (sometimes called stretch clustering), your cluster
server nodes can be spread across different subnets. This means that
you could failover to another geographical place in the world. SQL
Server 2012 supports geoclusters via Windows Server 2008 R2.
From a performance perspective, enabling
clustering doesn’t impact SQL Server performance as much as it did in
earlier versions. Prior to SQL Server 2012, tempdb had to be placed on the shared drive as well, which caused performance issues if your applications heavily used tempdb. Now, this is no longer the case, and even in a failover cluster configuration, tempdb can be located on a local drive to the node.
Failover clustering is one of the most popular
high-availability features used within IT departments today. Proper
setup clustering depends on a variety of factors including the shared
disk infrastructure, networking configuration, and Windows Server
versions.
AlwaysOn Availability Groups
The AlwaysOn Availability Group feature has
evolved from database mirroring. While the plumbing is much different
with Availability Groups, the idea is similar to database mirroring.
With AlwaysOn Availability Groups, we can specify one or more databases
to fail over as a group. Now, when a failover occurs or we manually
issue a failover, all the databases defined within the Availability
Group will be failed over together. This failover can occur to a
failover partner known as an availability replica server, just like in
database mirroring; however, unlike database mirroring, AlwaysOn
Availability Groups allow you to have multiple availability replicas,
up to four.
Availability replicas can be written
to asynchronously or synchronously. The primary role availability
replica is the host of the database and supports read and write
queries. The secondary role availability replica supports active user
connects and read-only queries. One of these availability replicas can
be defined as the failover partner. A great user scenario for
connecting to a secondary role availability replicas would be for
reporting and database backups. Since these connections need to be
read-only, if a user submits a write query, the query will simply fail.
