Difference between revisions of "How to setup a synchronously Mirrored Database"

Revision as of 13:57, 5 November 2014

You are here:

Home  How to setup a synchronously Mirrored Database

In order to guarantee maximum resilience, it is possible to deploy two separate database servers. At this, only one database server is connected to the DLS(single node or cluster), while the data are mirrored on the other server.

In case the main server ("Principal") fails, the second server ("Mirror") assumes its function.

For database mirroring, two models are supported:

• Synchronous Mirroring: A third server ("Witness") monitors the state of the main server. If the Principal should fail, the Witness will switch over to the Mirror, which will hereby become the Principal. Moreover, the Witness checks whether all transactions have been completed on the Mirror, too. Thus it is ensured that no data loss will occur. However, the performance will be slightly lower than with asynchronous mirroring. Be aware that High Availability with guaranteed data loss prevention is possible only with synchronous mirroring.

• Asynchronous Mirroring: There is no Witness, and the switchover to the mirror server is done by "Forced Service", i. e., by the DLS.

System Requirements

The following requirements must be fulfilled for database mirroring:

• Microsoft SQL Server Enterprise Edition with latest Service Packs is installed on all servers needed for database mirroring (Principal, Mirror and Witness, where applicable).

• Microsoft SQL Server Management Studio has to be installed.

• At least the first DLS node should be installed because mirroring can be set up only for a DLS database that has already been set up. This is part of the installation process for the first DLS node.

• The service DeploymentService is stopped on all participating DLS nodes.

• For the DLS database (DLSdb), the recovery model "Full" is set.

• The size for the TransactionLog is unlimited.

As the transaction log can reach any size, it might occur that the hard disk in use gets full, which would lead to SQL server and DLS failure. Thus, create a backup plan according to your requirements, and save the transaction log regularly, in addition to the DLS data. This effects a reduction of the currently active transaction log. Moreover, the transaction log should be saved significantly more frequent than the data proper, in order to keep the file as small as possible. When a database backup is performed, a complementary .trn file is generated. Those files are the backups of the transaction logs. This process makes sure that the transaction log-File "DLS_Log.LDF" does not grow endlessly. The very first creation of a .trn file might take considerably longer when a very large "DLS_Log.LDF" file has to be processed.  A DLS database restore does not require a correspondant .trn file. However, it is recommended to keep the latest transaction log file for investigation purposes in case a problem should occur.

Procedural steps

Proceed with the following :

Be aware that when Database Mirroring is active,no restore or backups is possible.

1. On the machine that is to be used as Principal, connect via Microsoft SQL Server Management Studio to the Database Engine. To connect to the DLS dB instance enter the following information:

* - Server Name: <Principal SQL Server name>\DLS

* - Authentication: Windows Authentication

2. Select DLSdb in Microsoft SQL Server Management Studio and configure Full Recovery model.

3. It is recommended to set an unlimited file size in the Files submenu by selecting unrestricted growth for DLSdb and DLSlog.

4. Enter the Witness and Mirror databases as you did in step 1. Create the "endpoints" for database mirroring by executing the following commands at the Principal server and the Mirror server:

* 2220 as TCP listener port

* PARTNER role

* Use Windows Authentication (WINDOWS NEGOTIATE)

5. Create the Witness Mirroring endpoint in the Witness server too.This endpoint should have the following characteristics:

* 2220 as TCP listener port

* WITNESS role

* Use Windows Authentication (WINDOWS NEGOTIATE)

6. Now, generate a backup of the DLS database on the Principal server under ’Share’ folder:

Before executing the following query make sure that the 'Share' folder is empty. Any existing backup file in this folder will prevent script from running.

7. Prepare for database recovery at the Mirror server.Restore the files only of the db backup taken previously in the Principal server. In that way you get the logical and physical names of the backup files.

8. Using the filenames of the previous step, start the database recovery in Mirror \ DBData folder.

9. On the Principal, under ‘Share’ folder, generate a backup of the initial transaction protocol.

10. Subsequently, carry out the recovery of the transaction protocol in mirror.

11. DLS uses its own stored procedures in the master database, which are not comprised by the DLSdb backup and restore. Hence, the script create_master_usp.sql must be executed at the Mirror the first time the Mirroring is configured. You can find this script in:

 <DLS installation directory>\Tomcat5\webapps\DeploymentService\database\dbinstaller\mssql\DlsDb

Be aware that if Mirroring has been executed in the past then the script cannot run successfully.