DB2 10.5 for Linux, UNIX, and Windows

High availability through log shipping

Log shipping is the process of copying whole log files to a standby machine either from an archive device, or through a user exit program that is running against the primary database. A scheduled job on the standby issues the ROLLFORWARD DATABASE command at a specified interval to keep the standby current in terms of log replay.

To set up log shipping, you configure the database with user exit programs and log archiving enabled, initialize the standby, modify one of the sample user exit files (you can find more information about them in "Log management user exit samples") to either archive the logs to a shared device or send the log files to the standby's log path, and schedule a job so that the standby processes the log files. For a detailed overview of setting up log shipping, see the following article: article.

After your log shipping solution is configured, the standby database is continuously rolling forward through the log files that are produced by the production machine. When the production machine fails, a failover occurs (you either initiate the failover manually or create a script to do this) and the following takes place:

The remaining logs are transferred over to the standby machine.
The standby database rolls forward to the end of the logs and stops.
The clients reconnect to the standby database, which is now the new primary, and resume operations.

The standby machine has its own resources (for example, disks), but must have the same physical and logical definitions as the production database. When using this approach, create the initial standby database by using restore utility (from a backup of the primary database) or by using the split mirror function if that is available.

To ensure that you are able to recover your database in a disaster recovery situation, consider the following recommendations:

Ensure that the archive location is geographically separate from the primary site.
Remotely mirror the logs at the standby database site.
Use a synchronous mirror for no-loss support. You can do this using modern disk subsystems such as ESS and EMC, or another remote mirroring technology. NVRAM cache (both local and remote) is also recommended to minimize the performance impact of a disaster recovery situation.

If you want to control which log files are to be rolled forward on the standby machine, you can disable the retrieval of archived logs by using the NORETRIEVE option with the ROLLFORWARD DATABASE command. The benefits of this option are as follows:

By controlling the log files to be rolled forward, you can ensure that the standby machine is X hours behind the production machine, which avoids affecting both the systems.
If the standby system does not have access to archive (for example, if Tivoli® Storage Manager is the archive, it allows only the original machine to retrieve the files).
It might also be possible that while the production system is archiving a file, the standby system is retrieving the same file, and it might then get an incomplete log file. The NORETRIEVE option solves this problem.

Note:

When the standby database processes a log record which indicates that an index rebuild took place on the primary database, the indexes on the standby server are not automatically rebuilt. The index is rebuilt on the standby server either at the first connection to the database, or at the first attempt to access the index after the standby server is taken out of the rollforward pending state. It is recommended that the standby server be resynchronized with the primary server if any indexes on the primary server are rebuilt. You can enable indexes to be rebuilt during rollforward operations if you set the logindexbuild database configuration parameter.
If the load utility is run on the primary database with the COPY YES option specified, the standby database must have access to the copy image.
If the load utility is run on the primary database with the COPY NO option specified, the standby database must be resynchronized or the table space is placed in restore pending state.
There are two ways to initialize a standby machine:
1. By restoring to it from a backup image.
2. By creating a split mirror of the production system and issuing the db2inidb command with the STANDBY option.
Only after the standby machine is initialized can you issue the ROLLFORWARD DATABASE command on the standby system.
Operations that are not logged are not replayed on the standby database. As a result, it is recommended that you resynchronize the standby database after such operations. You can do this resynchronization through online split mirror and suspended I/O support.