Roles of the Database Mirroring Configuration
As you have seen, a typical
database mirroring configuration has a principal server, mirror server,
and witness server. Each of these servers plays a role at some point.
The principal and mirror switch roles, so it is important to understand
what these roles are and when a server is playing a particular role.
Playing Roles and Switching Roles
A role corresponds to what a server is doing at a particular point in time. There are three possible roles:
Witness role—
If a server is playing a witness role, it is essentially standing
alongside both partners of a database mirror configuration and is used
to settle all arguments. It is getting together with any one of the
other servers and forming a quorum to come up with decisions. The
decision that it will participate in is whether to fail over. That is
it. As mentioned before, the witness server can be any edition of a SQL
Server (even SQL Server Express, the free version).
Principal role—
If a server is playing a principal role, it is the server that the
application will be connected to and that is generating the
transactions. One of the partners in the database mirror must start out
as the principal. After a failure, the mirror server takes over the
principal role, and the roles reverse.
Mirror role—
If a server is playing a mirror role, it is the server that is having
transactions written to it. It is in a constant recovery state (that is,
the database state needed to be able to accept physical log records).
One of the partners in the database mirroring configuration must start
out in the mirror role. Then, if a failure occurs, the mirror server
changes to the principal role.
Database Mirroring Operating Modes
With database mirroring, you have the option of deploying in one of three modes: high safety with automatic failover mode (high availability with a witness server), high safety without
automatic failover mode (high protection without a witness server), and
high-performance mode. Each mode has different failure and protection
characteristics and uses the database mirroring configurations slightly
differently. As you might expect, the high-performance mode offers the
least amount of protection; you must sacrifice levels of protection for
performance.
Database mirroring runs with either asynchronous or synchronous operations:
Synchronous operations—
With synchronous operations, a committed transaction is committed (that
is, written) on both partners of the database mirroring pair. This
obviously adds some latency cost to a complete transaction because it is
across two servers. High-safety modes use synchronous operations.
Asynchronous operations—
With asynchronous operations, transactions commit without waiting for
the mirror server to write the log to disk. This can speed up
performance significantly. High-performance mode uses asynchronous
operations.
Whether the operations
are asynchronous or synchronous depends on the transaction safety
setting. You control this setting through the SAFETY option when configuring with Transact-SQL (T-SQL) commands. The default for SAFETY is FULL (which provides synchronous operations). You set it to OFF for asynchronous operations. If you are using the mirroring wizard, this option is set for you automatically.
Of the three modes, only
the high safety with automatic failover mode (high-availability mode)
requires the witness server. The others can operate fine without this
third server in their configuration. Remember that the witness server is
looking at both the principal and mirror server and will be utilized
(in a quorum) for automatic failover.
Role switching
is the act of transferring the principal role to the mirror server. It
is the mirror server that acts as the failover partner for the principal
server. When a failure occurs, the principal role is switched to the
mirror server, and its database is brought online as the principal
database.
Failover variations are
Automatic failover—
Automatic failover is enabled with a three-server configuration
involving a principal, mirror, and witness server. Synchronous
operations are required, and the mirror database must already be
synchronized (that is, in sync with the transactions as they are being
written to the principal). Role switching is done automatically. This is
for high-availability mode.
Manual failover—
Manual failover is needed when there is no witness server and you are
using synchronous operations. The principal and mirror are connected to
each other, and the mirror database is synchronized. Role switching is
done manually. This is for high safety without automatic failover mode
(high-protection mode). You are making the decision to start using the
mirror server as the principal (no data loss).
Forced service—
In the case of a mirror server being available but possibly not
synchronized, the mirror server can be forced to take over when the
principal server has failed. This possibly means data loss because the
transactions were not synchronized. This is for either high safety
without automatic failover mode (high-protection mode) or
high-performance mode.
Setting Up and Configuring Database Mirroring
Microsoft uses a few
other concepts and technologies in database mirroring. You have already
learned about the copy-on-write technology. Microsoft also uses endpoints,
which are assigned to each server in a database mirroring
configuration. In addition, establishing connections to each server is
much more tightly controlled and requires service accounts or integrated
(domain-level) authentication. Within SQL Server, grants must also be
given to the accounts that will be executing database mirroring.
You can completely set up
database mirroring by using T-SQL scripts, or you can use the Database
Mirroring Wizard within SQL Server Management Studio (SSMS). We always advise
that you use something that is repeatable, such as SQL scripts, and you
can easily generate SQL scripts by using the new wizard. It’s not fun
to have to re-create or manage a database mirroring configuration in the
middle of the night. Having this whole process in a script reduces
almost all errors.
Getting Ready to Mirror a Database
Before you start setting up and
configuring a database mirroring environment, it is always best to run
through a simple checklist of basic requirements:
1. | Verify
that all server instances are at the same service pack level. In
addition, the SQL Server edition you have must support database
mirroring.
|
2. | Verify
that you have as much or more disk space available on the mirror server
as on the principal server. You also need the same room for growth on
both.
|
3. | Verify
that you have connectivity to each server from the others. You can most
easily do this by trying to register each SQL Server instance in SSMS.
If you can register the server, the server can be used for database
mirroring. Do this for the principal, mirror, and witness servers.
|
4. | Verify
that the principal server database that is to be mirrored is using the
full database recovery model. Right-click on the database you intend to
mirror, choose Tasks, and then Mirroring. This brings you to the
database mirroring properties dialog where you can configure mirroring.
If you try to start configuring database mirroring and the database
recovery model is not full for the principal database, you get a nasty
message to that effect (see Figure 1).
Because database mirroring is transaction log based, it makes sense to
be using the full database recovery model: all transactions are written
to the transaction log and are not truncated, as with other database
recovery models.
|
Before you go any
further, you must establish the endpoints for each of the servers that
will be a part of the database mirroring configuration. You can use the
Configure Security option of the wizard to do this, but getting into the
practice of using SQL scripts is really the best approach. Using SQL
scripts is very easy, as you will soon see.
Endpoints utilize TCP/IP
addressing and listening ports for all communication between the
servers. Within a server, the endpoint is given a specific name (that
is, an endpoint name) for easy reference and to establish the partner
roles that this server (endpoint) will possibly play. In addition, a
connection GRANT is needed for access to be
allowed from each server to the other, and a service account should be
used for this. This service account is usually a particular login that
is known to the domain and is to be used for all connections in the
database mirroring topology. Figure 2 shows the mirroring database properties of the AdventureWorks database on a SQL Server instance named SQL08DE01.
As you can see, no server network addresses are set up for database
mirroring of any kind, and the mirroring status says “This Database Has
Not Been Configured for Mirroring.”
Next, we look at how to set up
high safety with automatic failover mode (high-availability mode)
database mirroring with principal, mirror, and witness servers. For
this, you can mirror the old reliable AdventureWorks database that Microsoft provides with SQL Server 2008.
Figure 3 illustrates the database mirroring configuration to set up.
The initial principal server is the SQL Server instance named SQL08DE01, the initial mirror server is the SQL Server instance named SQL08DE02, and the witness server is the SQL Server instance named SQL08DE03.
You need to establish a local endpoint named EndPoint4DBMirroring9xxx
on each of these SQL Server instances and identify the TCP listening
port that will be used for all database mirroring communication. We also
like to embed the port number as part of the endpoint name, such as EndPoint4DBMirroring1430
for the endpoint that will be listening on port 1430. In our
configuration, the principal server will be listening on Port 1430, the
mirror server on Port 1440, and the witness server on Port 1450. These
port numbers must be unique within a single server machine, and the
machine name and port combination must be unique within the network. An
example of the fully qualified network address name of this server and
the listing port is TCP://REM1237433.ads.autodesk.com:1430, where REM1237433.ads.autodesk.com is the machine name within the domain, and 1430 is the listening port created with the endpoint. In addition, each server’s initial role needs to be specified. The SQL08DE01 instance can play any partner role (that is, a mirror and/or principal), the SQL08DE02 instance can play any partner role as well, and the SQL08DE03 instance should play the witness role only.
The first ones to look at are 2008 Create EndPoint Partner1.SQL, 2008 Create EndPoint Partner2.SQL, and 2008 Create EndPoint Witness.SQL. You can leverage these templates to start the setup process if you are not using the Configure Security Wizard.
Now that we’ve verified all aspects of our planned mirroring topology, let’s configure full database mirroring!
