Summary High Availability of SQL Server-Log Shipping [multiple figures]

Official reference: http://msdn.microsoft.com/en-us/library/ms187103.aspx

Overview

SQL Server uses log transmission, you can automatically back up transaction logs in the "primary database" on the "primary server" instance to one or more "secondary databases" on the separate "secondary server" instance ". Transaction log backup is applied to each secondary database. The optional third server instance (called the "monitoring server") records the history and status of backup and restore operations, and can trigger an alarm when these operations cannot be performed as planned.

Advantages

Provides disaster recovery solutions for a single primary database and one or more secondary databases (each database is located on a separate SQL Server instance.

Supports limited read-only access to secondary databases (during the interval between restoration jobs ).

The delay time is defined as the time between the backup time of the primary database log on the primary server and the backup time of the secondary server log that must be restored (application. For example, if the data on the primary database is accidentally changed, a long delay may be very useful. If unexpected changes are detected soon, you can retrieve unchanged data from the secondary database before the secondary database reflects the changes.

Terms and Definitions

Primary server: the SQL Server instance on the production server.

Primary database: the database on the master server of another server. All log transfer configuration Management performed through SQL Server Management Studio is executed in the master database.

Secondary server: the SQL Server instance in which you want to retain the hot standby copy of the primary database.

Secondary database: a hot backup copy of the primary database. Secondary databases can be in the RECOVERING or STANDBY state, which enables the database to be used for restricted read-only access.

Monitor server: an optional instance of SQL Server that tracks all detailed information transmitted by logs, including the time when transaction logs were last backed up in the primary database. The time when the secondary server last copied and restored the backup file. Information about any backup failure alarms.

Log transfer procedure

Log transmission consists of three operations:

Back up transaction logs in the master server instance.

Copy the transaction log file to the auxiliary server instance.

Restore the log backup in the secondary server instance.

Logs can be sent to multiple secondary server instances. In these cases, operations 2 and 3 are repeated for each secondary server instance.

The log transfer configuration will not automatically fail over from the primary server to the secondary server. If the primary database becomes unavailable, you can manually bring any secondary database online.

You can use the secondary database for report purposes.

In addition, you can configure alarms for log shipping configurations.

Typical log shipper configuration

The following figure shows the log transfer configuration with the master server instance, three secondary server instances, and one monitoring server instance. This figure illustrates the steps for backing up a job, copying a job, and restoring a job, as shown below:

The master server instance executes a backup job to back up transaction logs on the master database. Then, the server instance puts the log backup into the master log backup file (this file will be sent to the backup folder ). In this figure, the backup folder is located in the shared directory ("backup sharing.

All three secondary server instances execute their respective copy jobs to copy the primary log backup file to its local destination folder.

Each secondary server instance executes its restoration job to restore the log backup from the local destination folder to the local secondary database.

The primary and secondary server instances send their own historical records and statuses to the monitoring server instance.

 

Log Shipping configuration

Primary Server: SANZ-W7., starting the default database instance with local system

Primary Database: InsideTSQL2008

Secondary Server: WUW-W7., start the default database instance with the domain account wuwang, because if you use the Local System account, you cannot access network resources.

Secondary Database: InsideTSQL2008

Configuration steps:

Step 1:

Create a shared directory on the master server SANZ-W7 to give Everyone read permission. For example, the shared directory path I created is: C: TempLogShipping, and the shared path is: SANZ-W7LogShipping.

Step 2:

Make a full backup of the primary database InsideTSQL2008 (you can do not do a full backup, and do a full backup when configuring log shipping, as described below), and then put the backup file InsideTSQL2008.bak in C: under the TempLogShipping directory. Create the directory C: TempLogShipping on the secondary server.

Step 3:

Set the configuration attribute of LogShipping. Right-click InsideTSQL2008-> Tasks-> Ship Transaction Logs. The following figure is displayed:

 

Click Backup Settings for the following configuration:

 

A Job named LSBackup_InsideTSQL2008 is created here to automatically back up transaction logs.

Step 4:

Then add the Secondary server WUW-W7, as shown in the following figure:

 

Seconday server instance we choose WUW-W7, Secondary database by default is the same as the primary database InsideTSQL2008. As shown in the following figure, we can see two options in Initialize Secondary Database. One is to create a full database backup and then restore the full backup to the secondary Database, the other is to specify the path of the existing full backup.

 

Add the Secondary Server to the Copy File label to save the File path. Here we use the path with the same name. In addition, the secondary server also needs to start the SQL agent.

 

After the configuration is complete, click OK. A successful configuration page is displayed:

 

Log Shipping verification:

We view InsideTSQL2008 information under the service server WUW-W7, as shown in the following figure:

 

We can find that InsideTSQL2008 is in the Resotoring state, because the nonrecovery mode is used to restore to the service database.

After fully configuring Log Shipping, we can see the following Log backup files in the C: TempLogShipping Directory of the primary server:

 

In the C: TempLogShipping Directory of the Secondary server, you can see

 

The only difference is that the primary server has full database backup, but not in the Secondary server. Whether it's LSBackup_TESTDB1 on the primary server, or the LSCopy_SANZ-W7_TESTDB1 and LSRestore_SANZ-W7_TESTDB1 on the secondary server, I set them to execute every minute so that you can easily view the experiment results.

Solution to the "cocould not retrieve backup settings for primary ID" error

References: http://blogs.msdn.com/ B /sqlsakthi/archive/2012/06/14/error-quot-could-not-retrieve-backup-settings-for-primary-quot-in-log-shipping-backup-job.aspx

Check the running status of the Job LSBackup_InsideTSQL2008 in SSMS and find the Job reports an error as follows:

* ** Error: cocould not retrieve backup settings for primary ID 'f32baa93-0341-48b5-a5a0-2acde90283fa '. (Microsoft. SqlServer. Management. LogShipping)

* ** 19:30:15. 85 *** Error: Failed to connect to server WIN-E5EJQ0EN4O2. (Microsoft. SqlServer. ConnectionInfo)

* ** 19:30:15. 85 *** Error: A network-related or instance-specific error occurred while establishing a connection to SQL Server. the server was not found or was not accessible. verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider error: 40-cocould not open a connection to SQL Server )(. net SqlClient Data Provider)

* ** 19:30:15. 85 ----- end of transaction log backup -----

From the above error log we found that there was a saying that the server WIN-E5EJQ0EN4O2 could not be connected. But my primary server is a SANZ-W7, how is it a WIN-E5EJQ0EN4O2? This was when the system was installed, immediately installed SQL server, and then changed the host name from WIN-E5EJQ0EN4O2 to SANZ-W7. However, there is no update in sys. servers. You can view it using the following TSQL statement:

Select @ SERVERNAME

The query result is the WIN-E5EJQ0EN4O2. We only need to update the sys. servers information in the database. Run the following TSQL statement to update the server information.

-- Delete the old host name

EXEC sp_dropserver 'win-E5EJQ0EN4O2'

GO

-- Add the current host name

EXEC sp_addserver 'sanz-w7', 'local'

GO

After executing the preceding TSQL statement, remember to restart SQL server; otherwise, use select @ SERVERNAME to query whether the current server name or WIN-E5EJQ0EN4O2.