Using Replication and Database Mirroring Together
SQL
Server 2008 allows you to use combinations of options to achieve higher
availability levels. A prime example would be to combine data
replication with database mirroring to provide maximum availability of
data, scalability to users, and fault tolerance via failover,
potentially at each node in a replication topology. By starting with the
publisher and perhaps the distributor, you make them both database
mirror failover configurations. Figure 1
shows a possible data replication and database mirroring configuration
(database mirroring of the publisher and database mirroring of the
distributor).
Using database
mirroring and replication together is essentially the best of both
worlds: you get the super-low latency of database mirroring for fault
tolerance, and you get high availability
(and scalability) of data through replication. The downside of this
type of combined capability is that it requires additional servers (for
mirroring of the databases). The upside is the increased scalability and
resilience of your applications.
Using Database Snapshots from a Mirror for Reporting
A powerful configuration to
help offload reporting workload is to use database snapshots with
database mirroring. A database snapshot is a highly efficient feature of
SQL Server 2008 that allows for the generation and use of a read-only,
stable view of a database at a moment in time (hence, it’s called a
snapshot). The database snapshot is also created without the overhead of
creating a complete copy of the database or having completely redundant
storage. A database snapshot is simply a reference point of the pages
used in the database (that is defined in the system catalog). When pages
are updated, a new page chain is started that contains the data pages
changed since the database snapshot was taken, as illustrated in Figure 2.
As the original
database diverges from a snapshot, the snapshot gets its own copy of
original pages when they are modified. The copy-on-write technology used
for database mirroring also enables a database snapshot. When a
database snapshot is created on a database (a mirror database, in this
case), all writes check the system catalog of changed pages first; if
the snapshot is not there, the original page is copied (using
copy-on-write) and is put in a place for reference by the database
snapshot (because the snapshot must be kept intact). In this way, a
database snapshot and the original database share the data pages that
have not changed.
Unlike a mirror database, a database snapshot can be accessed by a reporting client in read-only mode, as shown in Figure 3. As long as the mirror server is communicating to the principal, reporting clients can access the snapshot database.
If the principal fails over
to the mirror server, the connections to the snapshot database are
disconnected during the database restart process (which makes the mirror
server the new principal server). It is possible to reconnect the
reporting clients to the database snapshot after a failover is
completed, but you must remember that now both the transactional clients
and reporting clients are connected to a single SQL Server instance.
This may not be acceptable from a performance point of view. Also, it is
always a good idea to keep the number of snapshots to a minimum when
creating them against a database mirror.
