Created by:

SQL Server
Robert Stewart

Last Updated:
July 16, 2020
High Availability
Course:
SQL710
• Transaction Log Shipping

• Database Mirroring

• Replication
Log Shipping
 1. Transaction log backup on principal
Transaction
Log
Shipping 2. Log backup streamed to destination server

3. Destination server does a restore on the log file

 • each server in the log shipping pair is completely independent: it has its own
storage and could theoretically be located anywhere in the world

• each database must be log shipped independently

• has no automatic failover process. It is a fully manual process to bring the new
server online and redirect all clients to the new server

• the destination database can be set to Standby mode

Transaction
Log • a log shipping source can be shipped to multiple destinations
Shipping
• log shipping can be set up between one version of SQL Server and the next. For
example, a SQL Server 2005 source database can log ship to a 2008 destination

• allows a user-specified delay between when the primary server backs up the
log of the primary database and when the secondary servers must restore
(apply) the log backup
Mirroring
Database
Mirroring
 1. The mirror instance identifies the log sequence number (LSN) of
the last transaction applied to the mirror database.

2. The mirror instance then obtains any outstanding transactions

from the transaction log of the principal database.

3. The outstanding transactions received from the principal

instance are written to the transaction log of the mirror
database and rolled forward.

4. The outstanding transactions to roll forward are known as the

redo queue, and the depth of this queue determines the catch-
Database up time and therefore the minimum time to fail over the
Mirroring principal role to the mirror database.
Process
5. As updates on the principal database continue, the transactions
are streamed from the principal’s transaction log to the mirror’s
transaction log and rolled forward on the mirror database. The
mirroring mode, asynchronous (high performance) or
synchronous (high safety), determines how the principal’s
transactions are sent and received.
 1. Transaction written to log
Database
Mirroring
High
2. Log record streamed to mirror
Performance
(Asynchronous 3. Transaction commits on the principal
Mode)
4. Log record written to transaction log

5. Transaction rolled forward on the mirror DB

 • does not have auto fail over capabilities like its counterpart synchronous mode. The failover
is generally a manual process

• to ensure closest point of failure you should attempt to backup the tail log from primary
server and restore it on the mirror before switching over

Database • asynchronous mode mirroring is typically used in disaster-recovery where the principal and
Mirroring mirror servers are in different physical locations and the network connectivity between them
High may lead to unacceptably large transaction latency under the synchronous mode
Performance
(Asynchronous
Mode) • if the possibility of some data loss is accepted as a consequence of the highest performance,
asynchronous mirroring presents a good disaster-recovery option, but for situations, in which
zero data loss is the target, consider high-safety synchronous mirroring
 1. On receiving a transaction from a client, the principal server writes the log for the transaction
to the transaction log

2. The principal server writes the transaction to the principal database and, concurrently, sends
Database the log record to the mirror server. The principal server waits for an acknowledgement from
Mirroring the mirror server before confirming either of the following to the client: a transaction commit
High Safety or a rollback
(Synchronous
Mode) 3. The mirror server hardens the log to disk, mirror returns an acknowledgement to the principal
server that it has hardened the transaction’s log to disk

4. On receiving the acknowledgement from the mirror server, the principal server will commit
the transaction and sends a confirmation message to the client of a commit

5. mirror writes to database

 • in synchronous mode the mirror is an exact copy of the principal at any given moment. In
contrast, a log shipping destination is typically at least 15 minutes behind the source

• needs to be set up on a database-by- database basis

• can be configured with a witness server to initiate automatic failover to the mirror server (high
safety)

• client connections can be automatically redirected to the mirror server on failure of the principal

• only a single mirror can exist for each principal

Database
Mirroring • the inability to read the mirror database (unless using a database snapshot), limits the use of
mirroring for reporting purposes

• secondary database is in an offline mode while mirroring is in place. This is to ensure integrity in
the secondary database in the event of a failover being required. Nothing can write to the
secondary database, so you know it will exactly match your primary

• can replicate schema changes. What this means is if you add a new index, or a new table, it will
automatically be mirrored over. This is not always the case with replication
Replication
 The replication model is based in a publisher/subscriber metaphor
with three distinct database roles

• publisher
Replication • subscriber
• distributor
 In most replication scenarios, the publisher is the production server that
accepts all transaction activity and makes that activity available for
replication to other servers. The publisher will generally store transactions
Replication to be replicated in its transaction log until the distributor picks them up for
Roles
Publisher
delivery.
 This is the service that is responsible for delivery of replicated data. In a
typical mode, the distributor will retrieve data from the log of the publisher
and store that data in its own log until it can distribute the data to the
Replication subscriber. It is essentially a store-and-forward service.
Roles
Distributor
 The subscriber receives the replicated data from the distributor. In most
cases this database must be treated as read only because the transaction
activity should occur on the publisher. There are exceptions to this rule,
Replication however, including Merge replication models and updating subscribers.
Roles
Subscriber
 • this is the standard replication model

• the publishing server stores transactions in its transaction log for replication

• periodically, a log reader service gathers the transactions and sends them to a distribution
server

• distribution server executes the transactions on each of the subscribing databases

Replication
Forms • this process can be scheduled to occur at regular intervals or can be configured to execute
Transactional whenever transactions commit on the publishing server

• distribution Agent transfers updates, inserts, deletes, and any other changes from the
distribution database to the Subscriber
 • takes images of the database at scheduled times of the changes recorded in your logs
since the last synch, and inserts them at a scheduled time

• while you can configure the frequency of replication, this approach works best when you
Replication
Forms have small volumes of data that are either nonvolatile or tolerate data latency
Snapshot
• If modifications to data or schema have been made at the Publisher, a new snapshot must
be generated in order to propagate modifications to the Subscriber
 • will merge content between databases so you can update data in both DB’s

• merge Agent uploads changes from the Subscriber to the Publisher and then downloads changes
from the Publisher to the Subscriber

Replication • conflicts, if any, are detected and resolved. Data is converged, and the Publisher and all Subscribers
Forms eventually end up with the same data values. If conflicts were detected and resolved, work that was
Merge committed by some of the users is changed to resolve the conflict according to policies you define.

o View and Resolve Data Conflicts for Merge Publications

o View Data Conflicts for Transactional Publications
 Push Subscription
This is a subscription model where the distributor services push data to the subscriber.
SQL Agent jobs running on the distributor will periodically connect to the subscriber and
execute transactions necessary to bring the subscriber current.

Pull Subscription
Replication This is a subscription model where the subscriber services retrieve transactions from the
Subscription distributor for execution to keep the subscriber current. Pull subscriptions allow some of
Models the overhead of replication to move from the distributor to the subscriber, which may load
balance the model better
 Article
An individual collection of replicated data usually associated with a table. Creating an article from a
table allows the administrator to filter out columns or rows that they want to exclude from the
replication scenario.

Publication
Replication A collection of articles usually associated with a database. A subscriber can either subscribe to an
Terms individual article or to the entire publication
 • It is possible to have multiple publishers replicate data to a single subscriber

• the data for each publisher article may even be published to the same table in the
Replication subscriber as long as each publisher’s data is distinct
Topologies
Central • this pattern is most common where there is a centralized data need for reporting or
Subscriber decision making
 • a single publisher can partition data to various subscribers

• assuming that each subscriber only needs a subset of the data, the administrator creates
multiple articles, each one filtering out data for a particular subscriber each subscriber can
Replication then receive the relevant data for them
Topologies
Central • this approach is useful when data is centrally collected but must be distributed locally for
Publisher decentralized processing
 • when data must replicate to more than one subscriber, but those subscribers are
geographically located where it is either expensive or impractical to perform a direct
replication

Replication • all data will replicate to a single subscriber that has more convenient access to the
Topologies ultimate subscribers
Distributed
Subscriber/ • the subscriber then republishes that data to the subscribers that need the data
Publisher
• the central server is responsible for both subscription and publication services