Database mirroring is such a huge technology jump in
capabilities that even the smallest company can now provide
near-real-time database failover without the fancy, expensive hardware
required with more complex configurations, such as with SQL Server
Clustering (that is built on Microsoft Cluster Services [MSCS]). MSCS
requires shared resources, separate network connections for internal
heartbeat communication, and so on. In addition, multiple layers of
software are involved (MSCS plus SQL Server). With database mirroring,
you can set up a near-real-time database failover environment using all
conventional, low-cost machines, without any complex hardware
compatibility requirements, and database mirroring can fail over in as
little as 3 seconds!
Database mirroring
effectively allows anyone to immediately step up to nearly 99.9% (at
least three nines) availability at the database layer at a very low
cost, and it is easily configured and managed.
What’s New in Database Mirroring
Performance, performance, and
more performance! This is the key improvement for database mirroring in
SQL Server 2008. This performance improvement was brought about by
Microsoft’s efforts to isolate and resolve the bottleneck in database
mirroring that existed with SQL Server 2005. That bottleneck centered
around the bulky transmission of full-size log records from one SQL
Server to another. Improvements in SQL Server 2008 are centered around
the data compression used on the log records sent from one server to the
other.As records are being
written to the mirror, automatic page repair can occur if SQL Server
finds any page that is not intact, adding more reliability and stability
to the overall SQL Server platform. A few more interesting performance
counters and new dynamic management views that provide visibility into
the health of your mirroring implementation round out the new features.
Microsoft SQL Server 2008 is
shifting very strongly to a goal of providing a Database Engine
foundation that can be highly available 7 days a week, 365 days a year.
With database mirroring, Microsoft is providing the masses with the
opportunity to achieve that dream much more quickly. Database mirroring
was first introduced in SQL Server 2005. It was earlier known as
Real-time Log Shipping (RTLS) and then had another name for a while, and
it finally ended up being called database mirroring—which is what it really is.
The key breakthrough that
allowed Microsoft to offer database mirroring was something called
“copy-on-write” technology. We describe it in more detail in a bit.
Suffice it to say that with copy-on-write technology, a transaction can
be distributed (that is, written) to another completely separate SQL
Server database immediately, and that other database can, in turn, be
used as a failover (that is, it can be used to fail over to in less than
3 seconds).
Fortunately,
the 2005 version of the AdventureWorks database can be installed using
the same installer that installs the AdventureWorks2008 or
AdventureWorks2008R2 database. If you didn’t install AdventureWorks when
you installed either of these sample databases, simply relaunch the
installer and choose to install the AdventureWorks OLTP database.
What Is Database Mirroring?
When you mirror a database,
you are essentially asking for a complete copy of a database to be
created and maintained, with as much up-to-the-second completeness as
possible; you are asking for a mirror image. Database mirroring is a
database-level feature. This means that there is no support for
filtering, subsetting, or any form of partitioning. You mirror
a complete database or nothing at all. This limitation actually keeps
database mirroring simple and clean to implement. It also certainly
provides some drawbacks, such as burning up twice the amount of disk
storage, but what you get in return is well worth the cost in storage.
Database mirroring works
through the transaction log of the principal database (of the database
that is to be mirrored). You can mirror only a database that uses the
full database recovery model. Otherwise, it would not be possible to
forward transaction log entries to another server. Through the use of
copy-on-write technology, a change to data in a primary server’s
database (as reflected in active transaction log entries) is first
“copied” to the target server, and then it is “written” (that is,
applied or restored) to the target database server (that is, to the
mirror server) transaction log. That is why it’s called copy-on-write.
Database mirroring is
very different from data replication. With replication, database changes
are at the logical level (insert, update, delete statements; stored
procedure executions; and so on), whereas database mirroring uses the
actual physical log entries on both the primary database server side and
the mirror database server side. Effectively, the physical “active” log
records from the transaction log of the principal database are copied
and written directly to the transaction log of the mirror database.
These physical log record-level transactions can be applied extremely
quickly. As these physical log records are being applied to the mirror
database, even the data cache reflects the forward application of the
log records. This makes the entire database and data cache ready for the
principal to take over extremely quickly. And, now with SQL Server
2008, the log records are compressed on the principal side before
transmission, which allows more records per transmission to be sent to
the mirror server, thus speeding up the whole topology quite a bit.
Figure 20.1 shows a typical database mirroring configuration that has three components:
Principal database server—
This is the source of the mirroring. You can mirror one or more
databases on a single SQL Server instance to another SQL Server
instance. You cannot mirror a database on one SQL Server instance to
itself (that is, the same SQL Server instance). Remember, you mirror a
database, not a subset of the database or a single table. It’s all or
nothing.
Mirror database server—
The mirror server is the recipient of the mirroring from the principal
database server. This mirrored database is kept in hot standby mode and
cannot be used directly in any way. In fact, after you configure
database mirroring, this database shows its status as being in
continuous “restore” mode. The reason is that the physical transaction
records are continuously applied to this mirror database. This database
is essentially a hot standby database and is not available for direct
database usage of any kind. The reason is that it is used in case the
principal fails and must not be tainted in any way (it must be the exact
mirror image of the principal. The one exception to this nonusage
scenario is creating database snapshots from the mirror database .
Witness database server— You
use the witness database server, which is optional, when you want to be
continually checking to see if any failures have occurred to the
primary database server and to help make the decision to fail over to
the mirror database server. Using a witness server is a sound way to
configure database mirroring. If you do not identify a witness server,
the principal and mirror are left on their own to decide whether to fail
over. With the witness server, a quorum is formed (that is, two out of
three servers), and it takes the quorum to make a failover decision. A
typical scenario is that the principal server fails for some reason, the
witness sees this failure, the mirror also sees the failure, and
together they agree that the principal is lost and that the mirror must
take over the principal role. If the witness still sees that the
principal is alive and well, but the communication between the mirror
and principal has been broken, the witness does not agree to fail over
to the mirror (even though the mirror thinks it must do this because it
lost connection to the principal). Witness servers are usually put on
separate physical servers.
Copy-on-Write Technology
The copy-on-write technology is at the core of the database mirroring capability. Look back at Figure 20.1, and notice what happens in a High Safety with Automatic Failover mode (synchronous mode):
A transaction from a client connection to the principal server (A) is written to the AdventureWorks database (D).
When
the transaction is written to the principal server’s transaction log,
it is immediately copied (B) and written to the mirror server (D).
When
this physical log record is written to the mirror server, it sends back
an acknowledgment (C) to the principal of its write success.
This is the copy-on-write
technology. The end result is that the mirror server is in exactly the
same state as the principal server (if the physical log record has been
successfully written on the mirror side). If failure occurs now, the
mirror server can pick up all processing from the clients extremely
quickly and without data loss.
Note
Database mirroring cannot be used for any of SQL Server’s internal databases—tempdb, masterdb, msdb, or modeldb. Database mirroring is fully supported in SQL Server Standard Edition, Developer Edition, and Enterprise Edition, but it is not
supported in SQL Server Workgroup Edition or Express Edition. However,
machines running these server editions could be used as witness servers.
When to Use Database Mirroring
Database mirroring elevates the availability level of a
SQL Server–based application to a very high level without any special
hardware and extra administration staff skills. However, when you should
use database mirroring varies depending on your true needs.
Basically, if you need to
increase the availability of the database layer, have automatic data
protection (that is, redundant storage of data), or decrease the
downtime that would normally be required to do upgrades, you should use
database mirroring. An ever more popular scenario for database mirroring
is when you need to offload reporting that is easily satisfied with
periodic database snapshots. This usage provides great relief from
heavily burdened transactional servers also used for reporting. Finally,
if you need data distribution, high availability, and high data
resiliency, using data replication with database mirroring is also a
good idea.
