SQL Server High Availability Solutions (Pros & Cons)
Disaster recovery in sql server
1. Rajib Kundu –Practice Lead, MS Dba
Services
Email:Rajib_Kundu@citagus.com
http://www.Citagus.Com
2. Agenda
Definitions
DR Plan Suggestions
Failover Cluster
Log shipping
Database Mirroring
Replication
3. Definitions
“Disaster recovery planning is the work that is devoted to preparing all
the actions that must occur in response to a disaster. The planning
includes the selection of a strategy to help recover valuable data.
The selection of the appropriate disaster recovery strategy depends
on your business requirements.”
Disaster Recovery Terminology
Recovery Time Objective – RTO
The amount of time system recovery must occur. This is
usually measured in hours.
Recovery Point Objective – RPO
The maximum amount of acceptable data loss. This is usually
measured in hours.
4. DR Plan Suggestions
Proper DR doc and ideally this would be written so
anyone would be able to understand it. Make it a living
document. It should be reviewed at least twice a year
because IT environments are constantly changing.
Need to test the plan at least twice in year to verify
we are ready to take any challenge
Stage simulated disasters to test your plan in a
realistic scenario.
Create an inventory of equipment you have so you
can easily replace it.
5. Prepare a DRP document
Include every possible information:
System architecture (How the
system/application works)
How many systems are involved and what their
names are.
Their IP Addresses, drive information, file
locations
Software installed, Contact information of
DBA‟s, or other key people.
Know your SLAs and choose appropriate
technology.
6. Prepare a DRP document(cont.)
Include every possible information…
Step by step guide on how to recover each of
your system based on different disaster
scenarios (Including timelines for recovery)
Security information, jobs/schedule
information, etc.
Make it a reminder for self that any system
changes should be updated in this guide.
Test, test and test!!!
9. Log Shipping
An automated method of maintaining a
warm standby server
Based on SQL Server's backup and restore
architecture. Uses the transaction log to
track changes
Relatively low-tech and inexpensive
„Ships' (copies and restores) a production
server's transaction logs to a standby server
11. Database Mirroring
Newly introduced with SQL Server 2005.
Maintains a copy of the principal database
as a mirror.
Transfers log records from principal to
mirror server instance.
Works with all hardware that supports SQL
Server 2005.
Automatic client redirection (using .NET 2.0)
Can have a third optional server called
Witness server for Auto Failover.
12. Database Mirroring -Synchronous
1 Acknowledge
Commit
7 Acknowledge
6
Constantly
2 redoing on mirror
Transmit to mirror
Write to
2 4
local log Committed Write to
in log remote log
3 5
DB Log Log DB
13. SQL Server – Peer-to-peer
Trans. Replication
Peer-to-peer transactional replication is designed for
applications that might read or might modify the data in
any database that participates in replication.
Additionally, if any servers that host the databases are
unavailable, we can modify the application to route
traffic to the remaining servers. The remaining servers
contain identical copies of the data.
14.
15. Disaster Recovery
Summary
Disaster Recovery is a spectrum of
strategies and solutions from 24x7x365
availability through no recovery at all
Even the best BC plan cannot
anticipate all recovery scenarios –
some ad-hoc procedures may be
needed during implementation to
minimize data loss
Failover clusteringMicrosoft SQL Server failover clustering is designed to failover automatically if a hardware failure or a software failure occurs. You can use SQL Server failover clustering to create a failover cluster for a single instance of SQL Server 2000 or for multiple instances of SQL Server 2000. Failover clustering allows a database system to automatically switch the processing of an instance of SQL Server from a failed server to a working server. Therefore, failover clustering is helpful if an operating system failure occurs or if you perform a planned upgrade of the database system resources. Also, failover clustering increases server availability with no downtime.Because failover clustering is designed for high server availability with almost no server downtime, the clustered nodes should be geographically close to each other. Failover clustering may not be useful if a disk array failure occurs.
Can be done between 32 bit and 64 bitAdvantage You have high server availability. Failover clustering automatically occurs if the primary server fails. Disadvantages You incur a greater expense. The maintenance of two servers is two times the cost of maintaining a single server. Because you have to maintain two servers at the same time, it is more expensive to install and maintain clustered nodes. Servers should be in the same location. If the branches of the organization are across the globe and the Active/Active clusters must be implemented in the branches, the networking and the storage infrastructure that you have to use is very different from a standard quorum device server cluster. Therefore, although it is possible, it is best not to use geographically distant servers. You have no protection against a disk array failure. Failover clustering does not allow you to create failover clusters at the database level or at the database object level, such as the table level.
The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restore jobs, as follows:1. The primary server instance runs the backup job to back up the transaction log on the primary database. This server instance then places the log backup into a primary log-backup file, which it sends to the backup folder. In this figure, the backup folder is on a shared directory—the backup share.2. Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its own local destination folder.3. Each secondary server instance runs its own restore job to restore the log backup from the local destination folder onto the local secondary database.
Advantages Database mirroring increases data protection. Database mirroring increases availability of a database. Database mirroring improves the availability of the production database during upgrades. Disadvantages The mirror database should be identical to the principal database. For example, all objects, logins, and permissions should be identical. Database mirroring involves the transfer of information from one computer to another computer over a network. Therefore, the security of the information that SQL Server transfers is very important.
Advantages Read performance is improved because you can spread activity across all nodes. Aggregate update performances, inserts performance, and delete performance for the topology resembles the performance of a single node because all changes are propagated to all nodes. Disadvantages Peer-to-peer replication is available only in SQL Server 2005 and 2008 Enterprise Edition. All participating databases must contain identical schemas and data. We recommend that each node use its own distribution database. This configuration eliminates the potential for SQL Server 2005 to have a single point of failure. We cannot include tables and other objects in multiple peer-to-peer publications within a single publication database. We must have a publication enabled for peer-to-peer replication before you create any subscriptions. We must initialize subscriptions by using a backup or by setting the value of the subscription synchronization type to replication support only. Peer-to-peer transactional replication does not provide conflict detection or conflict resolution. We recommend that you do not use identity columns.
