Pros and Cons
One of the key advantages of log shipping is
that you can have multiple secondary servers. Before SQL Server 2012
and AlwaysOn Availability Groups, there wasn’t an easy way to replicate
across more than one secondary. The performance impact is relatively
minor, because it’s only that of a database backup on the production
server.
There are a few cons with transactional log
shipping. Since we are shipping a single database, it does not include
automatically all the server objects like SQL Server logins and SQL
Server Agent jobs that may be related to the database being shipped.
For applications that leverage multiple databases, this solution may
not be the best in a failover situation. Also, there is no concept of
automatic failover, since all we are really doing is creating some SQL
Server Agent jobs to do a database backup, file copy, and database
restore.
3. Replication
When the scope of the data that we want to
replicate is almost the size of the database, we use features like log
shipping or database mirroring to ensure we have two or more copies of
the data. If what you are looking for is a subset of the data to be
replicated, you could use one of the three types of replication:
snapshot, merge, and transactional. In a high availability scenario, we
could replicate only those tables and objects that are absolutely
necessary for our applications to work. Replication usually isn’t the
main solution for high availability, but it is important to have a
basic understanding of this technology as it is widely used for other
scenarios.
In a replication solution, there are three common components: a publisher, a distributor, and a subscriber. A publisher
is the source of the replicated data, and it defines one or more
publications. Each publication contains one or more articles. These
articles define which particular data and objects such as stored
procedures, views, and user-defined functions should be replicated. A subscriber uses a subscription that either pushes or pulls the source data. The distributor
is a database instances that keeps track of the subscriptions for
various publishers. In some cases, the subscriber gets its data
directly from the publisher, and in other configurations, it gets its
data from the distributor. In the case of a local distributor, a single
distributor can act as both the publisher and the distributor. This is
a common configuration. If the distributor is on a separate database
server instances, it is known as a remote distributor.
Snapshot Replication
Snapshot replication is used when refreshing
the entire dataset is easier than replicating portions of it. Consider
the scenario where we have an online product catalog. The database that
the web page uses to get the information might be getting this data
from other database instance in the manufacturing group. Since the web
pages will never update the product catalog, they can receive a fresh
copy of the catalog when needed.
Snapshot replication is also used as an initial
step in other forms of replication. Just as a full database backup is
restored on the secondary before log shipping can begin, snapshot
replication can be used as the initial dataset for transactional
replication.
Merge Replication
Merge replication will send only the changes
made to the data at scheduled intervals. Consider the scenario where we
have sales people connecting to our corporate network periodically to
update the Sales database. The orders that the sales people enter are
unique, so updating these within the same database doesn’t lead to many
conflicts. The new updates and inserts done by the sales people are
merged in with the data created by the other sales people. If a
conflict does occur, there are ways to detect and resolve conflicts
automatically.
Transactional Replication
Out of the three core replication topologies,
transactional replication is the most popular one to implement from a
high-availability standpoint. Transactional replication replicates data
from the publisher to the subscriber each time a transaction completes
at the publisher.
Note
If you consider transactional replication as part of your high
availability story, it is important to note that there is no automatic
failover of clients using any replication topology. Setup and
troubleshooting of replication is more difficult than other
technologies like database mirroring.
4. Database Mirroring
Database mirroring takes the concept of log
shipping and builds it inside the SQL Server engine. Instead of
periodically packaging up the transaction log and sending it to a
secondary server, database mirroring opens a connection to the remote
server and sends the transactions themselves. Since it’s built within
the SQL Server engine, database mirroring can perform synchronous
two-phase commits with a secondary server. Database mirroring also
supports automatic failover via passing a failover partner parameter in
the connection string.
Motivation and Benefits
Database mirroring resolves some of the
downfalls of log shipping. The idea behind log shipping is to
periodically send the transaction log out to secondary servers, so
those servers have an exact copy of the primary database. Given the
transaction log backup time—the time it takes to copy the log file to
the secondary server and restore the backup on the secondary server—you
can imagine that there is no way for us to have an exact replica on the
secondary. This is one of the downfalls of log shipping; it is not
possible to guarantee a transactionally consistent secondary server. In
addition, it is not possible to perform an automatic failover. Upon a
failure of the primary, someone would have to tell the secondary that
it’s now the primary. In addition, applications that connect to a
primary server will have to know where the secondary server is and
reconnect the application to that secondary. It is out of these
deficiencies with log shipping that database mirroring was born.
Note
Database mirroring, similar to log shipping, provides protection at the
database-level instance. The database that is the source of the mirror
is the called the principal. The destination of the mirror is called the mirror. Together, this setup is called the database mirroring session.
With database mirroring, you can only have one mirror in the database
mirroring session. This is one of the more significant limitations of
database mirroring. Some DBAs use log shipping when they want more than
one remote copy of the.
Modes of Operation
Database mirroring has two modes of operation:
high safety and high performance. You can think of high-safety mode as
a synchronous mode and high-safety mode as asynchronous. In high-safety
mode, transactions are committed on both the principal and mirrored
servers, which decreases the overall performance but ensures that you
will always have two copies of the same data. In high-performance mode,
the mirror database makes the best effort to keep up with the
transactions sent from the primary. There can be a lag in this
configuration. However, the performance improvements with asynchronous
communication will most likely outweigh the risk of the small data loss
in the event of a total failure.
There is another mode of operation that is a
variation of high-safety called high safety with automatic failover.
This configuration is the same as high safety, except that there is
another separate SQL Server instance called the witness server.
The witness server’s job is to know if the principal database is
offline. It will issue an automatic failover if it can not connect to
the primary and it has a connection to the mirrored database. The SQL
Server instance that is the witness server does not have to be
dedicated. You can easily leverage an existing SQL Server instance for
this role.
