How to setup a synchronously Mirrored Database
The Wiki of Unify contains information on clients and devices, communications systems and unified communications. - Unify GmbH & Co. KG is a Trademark Licensee of Siemens AG.
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.
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.