Log Shipping, Mirroring, Replication and Clustering Which should I use? That depends on a few questions we must ask the user. We will go over these questions at the end.

Log Shipping This solution is used to keep DBs in sync on two separate servers. The first step of the process is to make a full backup of the DB and restore in on the secondary server. This can not be done for system DBs (master, model, msdb and tempdb). After the full, regular transaction logs are taken, copied to the secondary server and applied. Described:

Log Shipping This is a DR solution only Secondary DB can have two modes: Recover or Standby Readonly In SQL 2000 only the Enterprise edition allowed log shipping SQL Workgroup, Standard and Enterprise Both boxes should be same version for log shipping (ie both 2005 Standard) with the same patch level. Facts:

Log Shipping All DB changes to the primary DB are sent to the secondary. DDL and DML You can not run any other transaction logs outside of log shipping or you will break the log shipping. If the secondary box is being used for log shipping only it does not need to have a SQL license and can be failed over to for up to 30 days. This can be used to migrate to a higher version. Facts continued:

Log Shipping Easiest way to get security to work for this is to run SQL services on both boxes with the same domain login or same local login and password. Copy all of the logins from the primary box to the secondary box. Use the stored procedure sp_help_revlogin from Microsoft. Customer must be aware that future login changes must be done manually to secondary box. Copy all jobs that might be needed to secondary server. Disable the schedule. Customer must be aware that future login changes must be done manually to secondary box. Prework:

Log Shipping Create a share on the primary box where the transaction log backups will be written to. The login that is running the SQL Agent on the secondary box must have read access to this share. Make sure DB on primary server is set to full recovery mode. Register both SQL instances on main box to make sure security issues are fixed logged in with the account SQL is running under. Prework continued:

Log Shipping Login to secondary box and copy small file from created share on primary box. Prework continued:

Log Shipping There are three methods to copy new DB to secondary server: a. Manually do full backup, copy and restore (you must restore the DB in norecovery mode). b. Have log shipping do it. c. Have log shipping restore flat file backup that has been copied to new box. Setup:

Log Shipping Note if the DB is large (> 5 gigs) having SQL do backup and copy might time out. You must fill in three fields to get log shipping to work. You can take defaults on the rest. a. Share on primary for secondary to copy backups from. b. Location on primary box to write logs. c. Location on secondary box to copy logs to. Setup continued:

Log Shipping The default for the log shipping backups is every 15 minutes. This can be set to any time. It is normally not recommended to do less than 5 minutes or the system might not keep up. If you let log shipping create the new DB be careful because it will use the default directories for the files. Make sure there is enough space. Setup continued:

Log Shipping By default there is a three day retention on the log files on both boxes. This is normally a good setting. Once you setup the backups on the primary you can ship these to multiple boxes. After creating log shipping two jobs are created on the primary box and three on the secondary box. Setup continued:

Log Shipping The jobs created do all the work a. Primary: 1. Alert job – by default will alert if no backup has run for 1 hour. 2. Backup job – actually creates the transaction logs. b. Secondary: 1. Alert job – by default will alert if no restore has occurred for 45 minutes. 2. Copy job – copies backups to secondary box. 3. Restore job – restores job to secondary DB. Setup continued:

Log Shipping Simply run the following query: restore database your_db_name with recovery Note this will permanently break the log shipping. Bringing secondary DB on line:

Log Shipping Demo:

Mirroring Is a DR solution only Similar to log shipping, but transactions are copied individually as they happen. Two modes Synchronous and Asynchronous. Synchronous is a two phase commit. Both boxes must complete transaction before control is returned back to user. Described:

Mirroring Due to this it is recommend both boxes are in the same rack to keep this from affecting performance. Asynchronous only waits for primary box to commit. It guarantees the transaction will get to second box, but does not wait. This is only available in the Enterprise edition. Described:

Mirroring There is optional automatic failover. This involves a third SQL install called a Witness. The free Express edition can be used for this. If both the Witness and Secondary box can not connect to the Primary the Secondary takes over as the Primary. As with Log Shipping this can only be done on application DBs. The secondary DB will always show in a recovering state and not allow connections. All DB changes are copied to secondary DB. DDL and DML. Described:

Mirroring As with log shipping copy all logins and jobs to secondary box and then maintain changes. Run SQL on each box with same domain or local account. Login to each box and register all servers in SSMS. If this does not work there is a security issue. Prework:

Mirroring Make sure DB is in full recovery mode. Prework:

Mirroring Make a full backup of the DB and restore it on the secondary box. This must be done manually. Make sure to recover the DB is in no recovery mode. The Witness can be added at a later date. Certificates can be used to setup Mirroring: us/library/ms191140(SQL.90).aspx Setup:

Mirroring Manual failover can be done on the primary box by simply going into the mirror and clicking the failover button. If DB is in Asynchronous change it to Synchronous first before doing the failover to avoid data loss. Failover:

Mirroring If SQL finds a corrupt page in the primary DB it will check the secondary DB for the same page. If it is OK, SQL will copy it over and replace it on the primary box Change:

Mirroring Demo:

Clustering For SQL 2000 it was only available in Enterprise 2005 – Standard 2 nodes, Enterprise – Standard 2 nodes, Enterprise 16 This is for hardware redundancy only. It does not improve SQL performance Only the active nodes must have a SQL license. Described:

Clustering Shared storage must be used for a cluster. DAS or SAN at Rackspace. All DBs will exist on this storage including the system. SQL binaries must be installed on all boxes in the cluster. Note SSIS is not cluster aware. It must be installed on both nodes of the cluster and then the XML file and registry edited. There is an Axios doc on this. Described:

Clustering Reporting Services is not cluster aware and can not be setup like SSIS. It is not recommend to install RS on a cluster. Install it on a remote box and configure it to store it’s DBs on the cluster. All boxes of the cluster must be in the same DC. The cluster has its own name and IP, so the application does not know or care which node SQL is on. Described:

Clustering A manual failover will take approximately 30 seconds. A automatic cluster failover is dependent on what object failed. Different items will take longer than others for system to discover. Described:

Clustering Pictorial Demo:

Replication Three types: Transactional – 99% of setups Snapshot Merge It is used to copy usually part of a DB from one server to another. This is normally to allow reporting to be done on a box other than the primary or to avoid using slow linked servers. Described:

Replication The secondary DB is fully usable. Restrict logins on the secondary box. If replicated rows on it are updated or deleted it will cause replication to fail. Two parts: Publication – tables to be copied Subscription – servers to receive data Described:

Replication Similar to Mirroring in that transactions are normally copied as they occur. It can be setup to run on a schedule. Users can pick which tables to send, which columns to send and with a query what rows to send. The table must have a primary key to use in transactional replication. Transactional Replication Described:

Replication At a schedule time(s) of day all data from the chosen table(s) is copied and replaced on the secondary box. Normally this is used for reporting when 24 hour old data is OK and/or transactional replication puts to much load on the primary box. Snapshot Replication Described:

Replication Data is merged together between DBs. Conflict detection is needed. Normal application is stores sending their local data to home office with all data. Merge Replication Described:

Replication Only available in Enterprise. This is for scale out deployments. It is two way transactional replication. Improvements in 2008: 1. Can add new node without taking system off line. 2. If there is a conflict bad node is removed and others continue to work. Peer to Peer Replication Described:

Replication ‘Brain’ of replication. New system DB that gets created. Each publication must have a distributor, can be local and can be shared. Most of the work goes on here. In large systems the distributor is on it’s own box. It keeps track of what data must be moved. Distributor Described:

Questions to ask user Is automatic failover needed? Mirroring or cluster Auto failover in same data center? Cluster DR to different DCs? Log shipping or Asynchronous mirror Secondary DB must be accessible to users? Replication