> Expert > CommCell Recovery > CommServe Recovery > SQL Server Database Mirroring

Recovery Using SQL Server Database Mirroring: Building the Standby CommServe Host

Caution

SQL database mirroring is deprecated by Microsoft and may not be available in future versions of Microsoft SQL Server. Therefore, we recommend that you build the CommServe Disaster Recovery Using CommServe LiveSync For High Availability Disaster Recovery.

To enable CommServe disaster recovery using SQL Server database mirroring, you need to first build and configure database mirroring on the standby CommServe host.

In a database mirroring setup, CommCell services do not run at the same time on both the production CommServe host and standby CommServe host. If services are running on both, mirroring will be interrupted and the two CommServe databases try to communicate with the clients simultaneously.

Before selecting a database mirroring mode review the following:

Mode

Requires

Comments

High Safety with Automatic Failover (synchronous)

A witness server

The witness server instance can run on the same computer as the principal or mirror server instance, but this substantially reduces the robustness of automatic failover.

High Safety without Automatic Failover (synchronous)

Manual force of service with possible data loss on the standby CommServe host if the production CommServe host fails.

Database will be consistent with the last committed transaction.

High performance (asynchronous)

Manual force of service with possible data loss on the standby CommServe host if the production CommServe host fails.

  • Mirror database lags a small gap behind the principal database.

  • Mirroring has minimal impact on the production CommServe performance.

Procedure

The process flow for building the standby CommServe host involves the following tasks:

  1. Install the CommServe software on the production and standby CommServe host. See CommServe Installation.

    You can also use an existing production CommServe host for the configuration.

  2. Ensure that the CommServe Client Name on the standby CommServe is the same as the production CommServe. If necessary use the following command to rename the client name associated with the standby CommServe .

    setpreimagednames.exe CSNAME -instance instance001 -displayname <new display name> <old display name> -skipODBC -passiveCS

  3. Install latest software updates on the CommServe hosts.

    Make sure all the latest software updates that are installed on the production CommServe host are installed on the standby CommServe host. See Installing Service Packs.

  4. Disable the disaster recovery backup job schedules on the production and standby CommServe host. See Enabling or Disabling a Schedule.

  5. Configure an administrative user account to run SQL (CommVault) service on the production and standby CommServe host. Consult Microsoft manual for instructions.

  6. Stop Commvault services on the standby CommServe host. See Stopping a Service.

  7. Replicate the CommServe database and configure mirroring using the SQL Management Studio software. Consult Microsoft manual to perform the following tasks:

    1. Set the production CommServe database to Full Recovery mode.

      By default, a database in SQL Server is set to Simple Recovery Mode. In this mode, records of transaction log are kept as long as transactions are running. You must backup and restore all the transaction logs on the production CommServe. Therefore, set the CommServe database to Full Recovery mode to get full record of the transaction logs.

    2. Backup the production CommServe database.

    3. Backup the transaction logs of the production CommServe database.

    4. Copy the backup dump file(s) to the standby CommServe host using a physical media or a network drive that is accessible from both the servers.

    5. Restore the production CommServe database and transaction logs in NORECOVERY state to the standby CommServe host.

    6. Configure database mirroring on the production CommServe host.

    7. Schedule transaction log backups of the production CommServe database.

      To prevent database log growth, we recommend you to schedule transaction log backups of the production CommServe database every 15 minutes to an hour or more, depending on the frequency of activities on the CommServe.

      As an alternative, you can install the Microsoft SQL Server Agent on the production and standby CommServe hosts, and schedule transaction log backups with truncation. For instructions on installing the SQL Server Agent, see Preinstallation Checklist for the SQL Server Agent.

    Similarly, replicate other existing CommServe hosted databases (WFEngine, DM2, CvCloud, HistoryDB ) using the same procedure.

  8. Enable the disaster recovery backup job schedule on the production CommServe host.

  9. Disable auto start services for the standby CommServe host. From the Process Manager window, clear the Auto-start services when OS starts check box.

    if the Auto-start services when OS starts check box is grayed, run the following command to disable this option:

    GxAdmin.exe -consoleMode -setsvcstartmode manual

Note

Recommended: Configure an alert which notifies the user when any of the participating mirrored servers, either the production or standby server, undergo a state change. For example, from the synchronized state to a suspended or disconnected state. This operation is not mandatory to build the standby CommServe using SQL Database mirroring feature.

CommServe Recovery Using SQL Server Database Mirroring

Loading...