Microsoft SQL Server 2008 R2 Unleashed- P68 pptx

Data Replication and Database Mirroring for Fault Tolerance and High Availability SQL Server 2008 allows you to use combinations of options to achieve higher availability levels.. A pri

CHAPTER 19 Replication

Setting a minimum amount of memory allocated to SQL Server by using the Min

Server Memory option to guarantee ample memory across the board

Using good disk drive physical separation rules, such as keeping the transaction log

on a separate disk drive from the data portion Your transaction log is much more

heavily used when you opt for transactional replication

Putting your snapshot working directory on a separate disk drive to minimize disk

drive arm contention You should use a separate snapshot folder for each publication

Publishing only what you need By selectively publishing only the minimum

amount of data required, you implement a much more efficient replication

configu-ration, which is faster overall

Trying to run snapshots in nonpeak times so your network and production

environ-ments aren’t bogged down

Minimizing transformation of data involved with replication

Log Shipping

If you have a small need to create a read-only (ad hoc query/reporting) database

environ-ment that can tolerate a high degree of data latency, you might be a candidate for using

log shipping Log shipping is still a feature for SQL Server 2008, but it will be deprecated

by the next release In other words, it might be easy to use and easy to manage, but it is

being phased out as a feature of SQL Server For this reason, we do not describe it in this

book (it is described in detail in SQL Server 2000 Unleashed, though) For those who have

current log shipping configurations, it is time to move to database mirroring This

transi-tion will be easy because the two capabilities are so much alike (Actually, many aspects of

database mirroring came from log shipping.)

Data Replication and Database Mirroring for Fault Tolerance and

High Availability

SQL Server 2008 allows you to use combinations of options to achieve higher availability

levels A prime example is combining data replication with database mirroring to provide

maximum availability of data, scalability to users, and fault tolerance via failover at

poten-tially each node in the replication topology You can start with the publisher and

distribu-tor, making them both database mirror failover configurations Building up a combination

of both options together is the best of both worlds: the super low latency of database

mirroring for fault tolerance and the high availability (and scalability) of data through

replication (For more information, see Chapter 20, “Database Mirroring.”)

Summary

Summary

Replication is a powerful feature of SQL Server that can be used in many business

situa-tions Companies can use replication for anything from roll-up reporting to relieving the

main server from ad hoc queries and reporting It is critical to let your company’s

require-ments drive the type of replication technique to use Determining the replication option

and configuration to use is difficult, but actually setting it up is reasonably easy Microsoft

has come a long way in this regard Peer-to-peer replication seems to have the most

promise of delivering master-master symmetric replication in a production environment

Microsoft’s overall architectural approach and implementation is the model for the

indus-try You should not be afraid to use this facility It is more than production-worthy, and

the flexibility it offers and the overall performance are just short of incredible, incredible,

incredible (replication humor for you)

In Chapter 20 we delve into the capability to make an image of a database (a mirror) for

failover purposes using the database mirroring mechanism available within SQL Server

2008 This is a landmark addition for SQL Server

This page intentionally left blank

Database Mirroring

IN THIS CHAPTER

What’s New in Database Mirroring

What Is Database Mirroring?

Roles of the Database Mirroring Configuration

Setting Up and Configuring Database Mirroring

Testing Failover from the Principal to the Mirror

Client Setup and Configuration for Database Mirroring

Migrate to Database Mirroring

2008 as Fast as You Can

Using Replication and Database Mirroring Together

Using Database Snapshots from a Mirror for Reporting

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

configura-tions, such as with SQL Server Clustering (that is built on

Microsoft Cluster Services [MSCS]) MSCS requires shared

resources, separate network connections for internal

heart-beat 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

compatibil-ity requirements, and database mirroring can fail over in as

little as 3 seconds!

Database mirroring effectively allows anyone to

immedi-ately step up to nearly 99.9% (at least three nines)

availabil-ity 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 Later in this chapter we show you some

CHAPTER 20 Database Mirroring

results of a benchmark involving SQL Server 2005 and SQL Server 2008 that show the

major impact of this enhancement In addition, 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

data-base 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)

NOTE

The examples in this chapter are based on the SQL Server 2005 version of the

AdventureWorks database rather than the newer AdventureWorks2008 or

AdventureWorks2008R2 sample databases used for many of the examples in the

other chapters in this book The reason for this is because Database Mirroring cannot

be implemented on a database that is also configured for FILESTREAM storage The

2008 and 2008R2 versions of the AdventureWorks database make use of

FILESTREAM storage

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

For more information on downloading and installing the AdventureWorks sample

data-bases, see the Introduction chapter

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

What Is Database Mirroring?

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

execu-tions; 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

physi-cal “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:

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

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

mirror-ing, 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

data-base 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

snap-shots from the mirror database (creating database snapsnap-shots with a database mirror

is described in more detail later in this chapter and in Chapter 32 “Database

Snapshots”)

CHAPTER 20 Database Mirroring

SQL Server 2008

Principal

Server

Adventure Works DB translog

SQL Server 2008

Witness Server MSDB DB

D

SQL Server 2008

Mirror Server

Adventure Works DB translog

D A

B C

Client Client Client Client

Network

FIGURE 20.1 A basic database mirroring configuration with principal, mirror, and witness

servers

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

mirror-ing 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

deci-sion 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):

Roles of the Database Mirroring Configuration

1 A transaction from a client connection to the principal server (A) is written to the

AdventureWorks database (D)

2 When the transaction is written to the principal server’s transaction log, it is

imme-diately copied (B) and written to the mirror server (D)

3 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

process-ing 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

support-ed 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

As mentioned earlier in this chapter, 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

data-base mirroring is also a good idea We discuss these latter two ideas later in this chapter

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

CHAPTER 20 Database Mirroring

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:

along-side both partners of a database mirror configuration and is used to settle all

argu-ments 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)

appli-cation will be connected to and that is generating the transactions One of the

part-ners 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

trans-actions 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:

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

without waiting for the mirror server to write the log to disk This can speed up

per-formance significantly High-perper-formance 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

Setting Up and Configuring Database Mirroring

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

configura-tion involving a principal, mirror, and witness server Synchronous operaconfigura-tions 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

you are using synchronous operations The principal and mirror are connected to

each other, and the mirror database is synchronized Role switching is done

manu-ally 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)

syn-chronized, 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