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 the operating system or hardware, other software packages, update a fixpack for 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.

Note: This procedure cannot be used when upgrading your Db2 database product software to a new major release. The procedure to upgrade your Db2 database product software to a new major release is described in Upgrade Db2 High Availability Disaster Recovery (HADR) environments.

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. Note that the following update procedures are also not for an automated HADR environment. If you would like to proceed on performing rolling updates on an automated HADR environment, see Performing rolling updates in an automated Db2 high availability disaster recovery (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 update. 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.

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.5 to Db2 version 11.1. To upgrade a Db2 server in HADR environment see, ../../com.ibm.db2.luw.qb.upgrade.doc/doc/c0070028.html.

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: When performing a rolling update for applying a new Db2 fix pack, after the old standby database takes over as the new primary database, it would be running at a higher version of Db2 than the old primary (new standby) database. The new primary will not accept connections from a standby running an older version of Db2, because the older version of the product might not understand the new log records generated by the new primary. In order for the new standby database to reconnect with the new primary database (that is, for the HADR pair to reform), the new Db2 fix pack must also be applied to the new standby database.
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 db2updv111 only on the primary database.
After running the db2updv111 command, you might have to restart the database for changes from db2updv111 command to take effect. To perform a restart:
Attention: db2updv111 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.