DB2 10.5 for Linux, UNIX, and Windows

Performing rolling updates in a DB2 high availability disaster recovery (HADR) environment

Use this procedure in a high availability disaster recovery (HADR) environment when you upgrade software or hardware, update your DB2® database product software, or change database configuration parameters. This procedure keeps database service available throughout the rolling update process, with only a momentary service interruption when processing is switched from one database to the other. With multiple standbys, you can provide continued HA and DR protection throughout the rolling update process.

Before you begin

Note: This procedure is distinct from the HADR rolling update procedure for DB2 pureScale® environments, which is described in the following task: Installing online fix pack updates to a higher code level in a HADR environment

Review the system requirements for HADR. See System requirements for DB2 high availability disaster recovery (HADR).

If the hadr_syncmode database configuration parameter is set to SYNC, NEARSYNC or ASYNC, the HADR pair must be in a peer state before you start the rolling upgrade. If the hadr_syncmode database configuration parameter is set to SUPERASYNC, ensure that the standby database is not too far behind the primary database before you start the rolling update.

The HADR pair should be in peer state before starting the rolling update.

If you have two HADR databases (databaseA and database B) set up the following way, perform a role switch on one database so that both primaries are on the same system during the fix pack update:

The primary for databaseA runs on system1, and the standby runs on system2
The primary for databaseB runs on system2, and the standby runs on system1

The overall capacity of the databases might be reduced, but it keeps both database online during the procedure.

Note: All DB2 fix pack updates, hardware upgrades, and software upgrades should be implemented in a test environment before being applied to your production system.

About this task

Use this procedure to perform a rolling update on your DB2 database system, to perform maintenance on your DB2 pureScale cluster, and to update the DB2 database product software from one modification level to another. For example, applying a fix pack to a DB2 database product software. During rolling updates, the modification level or fix pack level of the standby database can be later than that of the primary database while testing the new level. However, you should not keep this configuration for an extended period to reduce the risk of using features that might be incompatible between the levels. The primary and standby databases will not connect to each other if the modification level of the DB2 database product software for the primary database is later than that of the standby database.

A rolling update cannot be used to upgrade from an earlier version to a later version of a DB2 database product software. For example, you cannot use this procedure to upgrade a DB2 database product from Version 10.1 to Version 10.5.

Procedure

To perform a rolling update in an HADR environment:

Update the standby database by issuing the following steps:
1. Use the DEACTIVATE DATABASE command to shut down the standby database.
2. If necessary, shut down the instance on the standby database.
3. Change one or more of the following: the software, the hardware, or the DB2 configuration parameters.
  Note: You cannot change any HADR configuration parameters when performing a rolling update.
4. If necessary, restart the instance on the standby database.
5. Use the ACTIVATE DATABASE command to restart the standby database.
6. Ensure that HADR enters peer state. Use the MON_GET_HADR table function (on the primary or a read-enabled standby) or the db2pd command with the -hadr option to check this.
Switch the roles of the primary and standby databases:
1. Issue the TAKEOVER HADR command on the standby database.
2. Direct clients to the new primary database. This can be done using automatic client reroute.
  Note: Because the standby database takes over as the primary database, the new primary database is now updated. If you are applying a DB2 fix pack, the TAKEOVER HADR command changes the role of the original primary database to standby database. However, the command does not let the new standby database connect to the newly updated primary database. Because the new standby database uses an older version of the DB2 database system, it might not understand the new log records generated by the updated primary database, and it will be shut down. In order for the new standby database to reconnect with the new primary database (that is, for the HADR pair to reform), the new standby database must also be updated.
Update the original primary database (which is now the standby database) using the same procedure as in step 1. When you have done this, both databases are updated and connected to each other in HADR peer state. The HADR system provides full database service and full high availability protection.
Optional: To enable the HADR reads on standby feature during the rolling update perform the following steps to ensure the consistency of the internal DB2 packages on the standby database before read operations are introduced. The binding of internal DB2 packages occurs at first connection time, and can complete successfully only on the primary database.
1. Enable the HADR reads on standby feature on the standby database as follows:
  1. Set the DB2_HADR_ROS registry variable to ON on the standby database.
  2. Use the DEACTIVATE DATABASE command to shut down the standby database.
  3. Restart the instance on the standby database.
  4. Use the ACTIVATE DATABASE command to restart the standby database.
  5. Ensure that HADR enters peer state. Use the MON_GET_HADR table function (on the primary or a read-enabled standby) or the db2pd command with the -hadr option to check this.
2. Switch the roles of the primary and standby database as follows:
  1. Issue the TAKEOVER HADR command on the standby database.
  2. Direct clients to the new primary database.
3. Repeat the same procedure in substep a to enable the HADR reads on standby feature on the new standby database.
Optional: If did not perform step 4 and you want to return to your original configuration, switch the roles of the primary and standby database as you did in step 2.
Optional: In an HADR environment, run db2updv105 only on the primary database. After running the db2updv105 command, you might have to restart the database for changes from db2updv105 command to take effect. To perform a restart:
Attention: db2updv105 might deactivate packages and a REBIND must be run. After the REBIND is complete, all packages are valid and the instances do not need to be recycled.
1. Restart the standby database by deactivating and reactivating it. The standby database is restarted to prevent the disruption of primary database service.
  1. Run the following command on the standby database:
```
DEACTIVATE
db dbname
```
    where dbname is the name of the standby database.
  2. Run the following command on the standby database:
```
ACTIVATE
db dbname
```
    where dbname is the name of the standby database.
2. Switch the roles of the primary and standby databases:
  1. Run the following command on the standby database:
```
TAKEOVER
hadr on db dbname
```
    where dbname is the name of the standby database.
  2. Direct clients to the new primary database.
    Note: The databases have switched roles. The primary database was previously the standby database and the standby database was previously the primary database.
3. Restart the standby database (formerly the primary database), using the same method as in Step 1.
4. Switch the roles of the primary and standby databases to return the database to their original roles. Switch the roles using the same method as in step 2.