Chapter 10: High Availability

8/14/2019 Chapter 10: High Availability

1/63


2/63

p. 1

Chapter 10: High Availability

1

Presented by Scott Whigham


3/63

p. 2

Ove

rview Overview of

Chapter

What isHighAvailability?

LogShipping&Mirroring Log

Shipping

DatabaseMirroring

Cluste

ring&Replication Clustering

Replication

Peer to PeerReplication

What Were Going to Cover


4/63

p. 3

Our final chapter is an overview of thevarious areas related to high availability

Log Shipping

Database Mirroring

Clustering

Peer-to-peer replication*

Not exactly high availability but often used in conjunction with the above



5/63

p. 4

High availability is a design that attemptsto ensure users always have access to the

database

Unplanned unavailability in some systems is notacceptable

Flight systems, emergency response teams, military

operations

Planned unavailability is allowed for maintenance

High Availability


6/63

p. 5

Availability and uptime are not the samething

A system can be up yet, if the network is down, it is

not available

Downtime could be a combination of things

Time spent identifying problem

Time spent repairing problem

Restore time

Service or OS restarts

High Availability


7/63p. 6

To calculate total availability of a system,summarize:

Network downtime

Application downtime

Database downtime

Operating system downtime

High Availability


8/63p. 7

To increase a systems availability Decrease the amount of downtime

Decrease the frequency of downtime

High Availability


9/63p. 8

Applications and services often featureservice level agreements (SLAs) that list

minimum availabilities:

90% availability means allowing 36.5 days ofunplanned unavailability

99% availability means allowing 3.65 days of

unplanned unavailability

99.999% (the five nines) availability means

allowing ~00:05:15 of unplanned unavailability

High Availability


10/63p. 9

As a SQL Server DBA, your job is toensure the availability and uptime of

your

Server/service Database(s)

High Availability


11/63p. 10

In this chapter, you will learn aboutvarious built-in techniques to help you

achieve high availability

Some are expensive to implement In all cases there are 3rd party solutions which may

offer better alternatives

Often you will combine techniques to increaseboth uptime and availability

Example: A clustered instance with database mirroring

High Availability


12/63p. 11

Lets get started with log shipping!

In the next video


13/63p. 1


1



14/63p. 2

Ove

rview Overview of

Chapter


LogShipping&Mir

roring Log

Shipping

DatabaseMirroring

Cluste


Replication




15/63p. 3

There are a few categories of BestPractices as relate to Log Shipping

Backup and Restore

Network

Security

Log Shipping Best Practices


16/63p. 4

Backup and Restore Best Practices forLog Shipping:

1. Give enough time for your backups to complete

If you schedule backups every 5 minutes and abackup takes 7 minutes to complete, what happens to

the next backup?

Answer: The next backup will not take place until the next

scheduled time



17/63p. 5

Backup and Restore Best Practices:2. The more frequently you backup, the larger

MSDB becomes

Check up on sp_delete_backuphistory stored proc

for clearing out msdb periodically

3. Use backup compression if you can

Makes for faster backups, faster network copies, and

faster restores - just make sure you have the CPUpower to do it!



18/63p. 6

Backup and Restore Best Practices:4. The more frequently you backup, the less

possible data loss at the target

SQL Server 2008 allows for as frequent as 10 seconds!



19/63p. 7

NetworkBest Practices for Log Shipping1. Fast networks are good; slow networks are bad



20/63p. 8

NetworkBest Practices for Log Shipping2. If you cant do native backup compression

(available in Enterprise only) and speed of filecopy is an issue, consider using 3rd party

compression It does no good to take backups every 5 mins if they

take 15 mins to copy

7-Zip is an industry favorite despite its beingunsupported

Depending on the type of data, can compress 1:1, 5:1,20:1 or more



21/63p. 9

SecurityBest Practices for Log Shipping1. Secure all folders that participate in log shipping

Having an unauthorized person get to backups is

terrible

Having a sysadmin who is trying to clean up disk

space delete critical backup files means you cannot

restore



22/63p. 10

SecurityBest Practices for Log Shipping2. Use your log shipping backups in your normal

disaster recovery scenario

When you take a log backup for log shipping, that is

your log backup for your local disaster recovery plan

as well

Make sure you copy to the same location as your

FULL/DIFF backups!



23/63

p. 1


1



24/63

p. 2

Ove

rview Overview of

Chapter


LogShipping&Mir

roring Log

Shipping

DatabaseMirroring

Cluste

ring&Repli

cation Clustering

Replication




25/63

p. 3

There are a few categories of BestPractices as relate to Database Mirroring

Architecture

Network Security is not generally in this list

All data transfer is encrypted if using same domain

Database Mirroring Best

Practices


26/63

p. 4

Architecture Best Practices for DatabaseMirroring:

Architecture is an all encompassing term that

can include Transaction safety levels

Editions used

Size of database(s)

Usage scenario(s)


Practices


27/63

p. 5

Architecture Best Practices for DatabaseMirroring:1. Transaction safety levels can influence the

performance of database mirroring

Safety OFF(i.e. asynchronous mirroring) means thattransactions are committed at principal without waitingfor confirmation from witness/mirror

If transactions cannot be sent, it forms a queue at principal

Safety FULL (synchronous mirroring) requiresconfirmation from mirror that the log has beenhardened


Practices


28/63

p. 6


1. Transaction safety levels can influence the

performance of database mirroring Because of how differently applications use a database,

it is impossible to just say, Always use Safety X

because it performs better

Only one thing you can do: read the whitepaper! http://technet.microsoft.com/library/cc917681.aspx


Practices


29/63

p. 7


2. Use Enterprise edition for maximum

configurability Standard edition can only run Safety FULL transaction

safety level

Safety FULL will have an impact on transaction throughput at

the principal

Thankfully log compression is enabled in both Standard

and Enterprise editions

Log compression is a new feature in SQL 2008


Practices


30/63

p. 8


3. Get creative when it comes to bulk imports

Database mirroring requires FULL recovery model You can:

Disable mirroring

Perform the steps to bulk import

Switch back to FULL recovery

Perform a log backup and restore the log backup at the target

Turn on mirroring again


Practices


31/63

p. 9

NetworkBest Practices for DatabaseMirroring:

1. Consider using database mirroring for local or

metro-area networks The farther away the servers are, the longer it takes

to stream the transactions

Also introduces higher potential for communication issues

Network roundtrip times can be 100x faster on a LANthan on a WAN (Wide Area Network)

1ms vs. 100ms


Practices


32/63

p. 10

NetworkBest Practices for DatabaseMirroring:

2. Faster networks mean promotions and plaudits

Slow networks mean updated resumes and m-e-e-t-i-n-g-s to explain why it doesnt work like the vendor

said it would


Practices


33/63

p. 1


1



34/63

p. 2

Overview Overview of

Chapter


LogShipping&Mir

roring Log

Shipping

DatabaseMirroring

Cluste


Replication




35/63

p. 3

There are a few categories of BestPractices as relate to SQL Clusters

Hardware

Installation Configuration

SQL Clustering Best Practices


36/63

p. 4

Hardware best practices involve:1. Do not use the quorum disk for any SQL Server-

related files

2. Use identical network adapters with identical

software/drivers

3. Manually set the speed and duplex mode of any

adapters that allow multiple speeds

Setting to Auto Select may result in dropped packets



37/63

p. 5

Hardware best practices involve (cont.):4. Since the clustered disks are a single point of

failure, ensure they are sufficiently redundant

RAID 10 is quite popular



38/63

p. 6

Installation best practices involve:1. Start the installation from the node that owns

the disk resources

2. If you have to install SQL 2008 onto a cluster

with SQL 2000 already on it, install SP4 for SQL

2000 on all nodes first, then install SQL 2008

onto the cluster

3. For a 2008 install onto a pre-existing 2005cluster, install SQL 2005 SP2 first and then SQL

2008



39/63

p. 7

Configuration best practices involve:1. On Active/Active clusters, make sure to set max

server memory for each instance so that you

allow for multiple instances running on one

node at the same time

2. Consider using a slipstreamed installation DVD

Slipstreaming is the process of creating an installation

media that already contains a service pack and/orhotfix



40/63

p. 8

Configuration best practices involve(cont.):

3. Integration Services is not installed as a clustered

resource

Although you could make it a clustered resource, it is

better to install it locally to each node



41/63

p. 1


1



42/63

p. 2


Chapter

What is

High

Availability?

LogShipping&Mirroring Log

Shipping

Database

Mirroring

Cluste


Replication




43/63

p. 3

Replicating data is the process of copyingdata and table definitions from database

to database

Example: User enters data at the Los Angeles server

Replication copies the change servers in Sydney,

London, and Mumbai

After copying the change, all servers have the samedata

SQL Server Replication


44/63

p. 4

Basic terms: Publisher: the source database

Publication: the tables, views, and stored

procedures that the publisher is publishing

Subscriber: the database receiving the

changes

Subscription: how the subscriber receives

the data

Distributor: the server responsible for

delivering the publication to the subscriber



45/63

p. 5


Publisher (source) Distributor Subscribers


46/63

p. 6

When the data is copied to a database, itis considered synchronized

Synchronization can be instant or scheduled

Instant- as the change is entered at Publisher it is

instantly replicated; Subscribers and Publisher always

have the same data

Scheduled- allows latency between when data is

entered at Publisher and when Subscribers have data



47/63

p. 7

There are three basic types of replication: Snapshot

Merge

Transactional Lets look at each!



48/63

p. 8

Snapshot replication: Publisher generates a snapshot- a point-in-time

copy of the publication

Distribution then replaces copy of subscribers

data with the snapshot

Typically one-way replication (data entered only at

publisher)

Analogy: Newspaper industry

Snapshot Replication

h l


49/63

p. 9

Snapshot Replication

h id


50/63

p. 10

Lets continue our tour of the types ofreplication with Merge and Transactional

In the next video


51/63

p. 1


1


Wh W G i C


52/63

p. 2


Chapter


LogSh

ipping&Mirroring Log

Shipping

DatabaseMirroring

Clustering&Replication Clustering

Replication



M R li ti


53/63

p. 3

Merge replication: Basic premise: Anyone can change the data

Transactions are replicated

Unlike Snapshot replication which replicates entire

snapshot

Changes are synchronized between all servers

Merge Replication

M R li ti


54/63

p. 4

Merge replication: Setup flow:

1. Create the publication and generate the snapshot

2. Distribute snapshot to subscribers

At this point, Publisher and Subscribers have same data

3. Someone changes the data (could be Pub or Sub)

4. Merge Agent handles merging the data so that, in the

end, everyone has the same data

Merge Replication

M R li ti


55/63

p. 5

Conflicts can occur in Merge Replication What happens when two sites change the same data

at the same time?

You can help lessen the chance of a conflict:

You can specify that changes to the same row by

different sites is allowed provided that they change

different columns

At synchronization, the Merge Agent merges the rowand synchronizes all servers so that everyone has the

same data

Merge Replication

M R li ti


56/63

p. 6

You can define how conflicts are resolvedin several ways:

By setting priority levels for each site

In the event of a conflict between two sites, the highest

priority sites changes win

By setting, First in wins or Last in wins

Whoever made the change first/last wins

By writing custom business rules

Merge Replication

Merge Replication


57/63

p. 7

Merge Replication

Transactional Replication


58/63

p. 8

Transactional replication: Transactions are replicated between servers

Transactional can:

Be one-way: only the Publisher can replicate changes

By multi-way: changes can occur at any site

Transactional may or may not have conflict

detection

Depends on topology Rule of thumb: Last in wins unless you configure

differently




59/63

p. 9


P2P Transactional Replication


60/63

p. 10

Peer to Peer (P2P Transactionalreplication:

Allows both scale-out and high availability

Easily scales since each site acts as Publisher and

Subscriber (called Nodes)

Every site has the same data so clients can connect to

any site thus allowing a degree of load balancing

If one site goes down, users just connect to another site

Debuted in SQL 2005




61/63

p. 11




62/63

p. 12

Conflicts can occur in P2P What happens when a user connected to the

Dallas node updates a row and, at the same time,

a user on the Houston node deletes that row?

Default: Last in wins

Can enable conflict detection - default setting is to

stop distribution when a conflict is found


Lets demo!


63/63

Lets demo P2P!

Let s demo!

Date post:	30-May-2018
Category:	Documents
Upload:	learnitfirst
View:	216 times
Download:	0 times

Chapter 10: High Availability

Documents