DB2 10.5 for Linux, UNIX, and Windows

Using a split mirror as a standby database in a DB2 pureScale environment

Use the following procedure to create a split mirror of a database for use as a standby database in a DB2® pureScale® environment. If a failure occurs on the primary database and it becomes inaccessible, you can use the standby database to take over for the primary database.

About this task

If the primary database was configured for log archiving, the standby database will share the same log archiving configuration. If the log archiving destination is accessible to the standby database, the standby database will automatically retrieve log files from it during rollforward operations. However, once the database is brought out of the rollforward pending state, the standby database will attempt to archive log files to the same location used by the primary database. While the standby database will initially use a different log chain from the primary database, the primary database could eventually use the same log chain value as the standby database. This could cause the primary database to archive log files on top of the log files archived by the standby database, or vice versa , and can affect the recoverability of both databases. You should change the log archiving destination for the standby database to be different from that of the primary database to avoid recoverability issues.

Procedure

To use a split mirror as a standby database:

Connect to the primary database using the following command:
```
db2 connect to <db_namd>
```
Configure the General Parallel File System (GPFS™) on the secondary cluster by extracting and importing the primary cluster's settings. On the primary cluster, run the following GPFS command:
```
mmfsctl <filesystem> syncFSconfig -n <remotenodefile>
```
where <remotenodefile> is the list of hosts in the secondary cluster.
List the cluster manager domain using the following command:
```
db2cluster -cm -list -domain
```
Stop the cluster manager on each host in the cluster using the following command:
```
db2cluster -cm -stop -host <host> -force
```
Note: The last host which you shut down must be the host from which you are issuing this command.
Stop the GPFS cluster on the secondary system using the following command:
```
db2cluster -cfs -stop -all
```
Suspend the I/O write operations on the primary database using the following command:
```
db2 set write suspend for database
```
Note: While the database is in suspended state, you should not be running other utilities or tools. You should only be making a copy of the database. You can optionally flush all buffer pools before issuing SET WRITE SUSPEND to minimize the recovery window. This can be achieved using the FLUSH BUFFERPOOLS ALL statement.
Determine which file systems must be suspended and copied using the following command:
```
db2cluster -cfs -list -filesystem
```
Suspend each GPFS file system that contains data or log data using the following command:
```
/usr/lpp/mmfs/bin/mmfsctl <filesystem> suspend
```
where <filesystem> represents a file system that contains data or log data.
Note: While the GPFS file systems are suspended, both read and write operations are blocked. You should only be performing the split mirror operations during this period to minimize the amount of time that read operations are blocked.
Create one or multiple split mirrors from the primary database using appropriate operating system-level and storage-level commands.
Note:
- Ensure that you copy the entire database directory, including the volume directory. You must also copy the log directory and any container directories that exist outside the database directory. To gather this information, refer to the DBPATHS administrative view, which shows all the files and directories of the database that need to be split.
- If you specified the EXCLUDE LOGS with the SET WRITE command, do not include the log files in the copy.
Resume the GPFS file systems that were suspended using the following command for each suspended file system:
```
/usr/lpp/mmfs/bin/mmfsctl <filesystem> resume
```
where filesystem represents a suspended file system that contains data or log data.
Resume the I/O write operations on the primary database using the following command:
```
db2 set write resume for database
```
Start the GPFS cluster on the secondary system using the following command:
```
 db2cluster -cfs -start -all
```
Start the cluster manager using the following command
```
db2cluster -cm -start -domain <domain>
```
Catalog the mirrored database on the secondary system.
Note: By default, a mirrored database cannot exist on the same system as the primary database. It must be located on a secondary system that has the same directory structure and uses the same instance name as the primary database. If the mirrored database must exist on the same system as the primary database, you can use the db2relocatedb utility or the RELOCATE USING option of the db2inidb command to accomplish this.
Start the database instance on the secondary system using the following command:
```
db2start
```
Initialize the database on the secondary system by placing it in rollforward pending state:
```
db2inidb <database_alias> as standby
```
If required, specify the RELOCATE USING option of the db2inidb command to relocate the database:
```
db2inidb database_alias as standby relocate using relocatedbcfg.txt      
```
where relocatedbcfg.txt contains the information required to relocate the database.
Note: You can take a full database backup using the split mirror if you have DMS table spaces (database managed space) or automatic storage table spaces. Taking a backup using the split mirror reduces the overhead of taking a backup on the production database. Such backups are considered to be online backups and will contain in-flight transactions, but you cannot include log files from the standby database. When such a backup is restored, you must rollforward to at least the end of the backup before you can issue a ROLLFORWARD STOP command. Because the backup will not contain any log files, the log files from the primary database that were in use at the time the SET WRITE SUSPEND command was issued must be available or the rollforward operation will not be able to reach the end of the backup.
Make the archived log files from the primary database available to the standby database either by configuring the log archiving parameters on the standby database or by shipping logs to the standby database.
Rollforward the database to the end of the logs or to a point-in-time.
Note: When executing rollforward operations, you might encounter SQL1273 errors. These errors are expected if some of the log files were not copied from the primary system when the database was split or if one member generates log files faster than other members. SQL1273 is generated in some cases when the rollforward operation must stop to preserve data consistency because the contents of the log files depends on the contents of unavailable log files from other members. If the standby database is configured to retrieve log files archived by the primary database, you can either wait for the primary system to archive the necessary log file or you can use the ARCHIVE LOG command on the primary system to force the log file to be archived. Otherwise, you must ship the required log files to the standby database. After the necessary log file is available on the standby database, the rollforward operation can read further ahead in the logs, although SQL1273 might be encountered again if some members are still generating log files faster than other members. For more information, see the "Disaster recovery and high availability through log shipping in a DB2 pureScale environment" section of the "Backup and restore operations in a DB2 pureScale environment" Information Center topic.
Continue the rollforward operation through the logs until you reach the end of the logs or the point-in-time required for the standby database, shipping new log files to the standby database if required.
Bring the standby database online by issuing the ROLLFORWARD DATABASE command with the STOP option specified.
Note:
- The logs from the primary database cannot be applied to the mirrored database once it has been taken out of rollforward pending state.
- If the primary database was configured for log archiving, the standby database will share the same log archiving configuration. If the log archiving destination is accessible to the standby database, the standby database will automatically retrieve log files from it while rollforward is being performed. However, once the database is brought out of rollforward pending state, the standby database will attempt to archive log files to the same location used by the primary database. Although the standby database will initially use a different log chain from the primary database, there is nothing to prevent the primary database from eventually using the same log chain value as the standby database. This may cause the primary database to archive log files on top of the log files archived by the standby database, or vice versa. This could affect the recoverability of both databases. You should change the log archiving destination for the standby database to be different from that of the primary database to avoid these issues.