Rolling updates with multiple HADR standby databases

Use this procedure in a high availability disaster recovery (HADR) environment with multiple standbys when you upgrade the operating system or hardware, other software packages, update a fix pack 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 this procedure, 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.

Multiple HADR standbys allow you to use the rolling update procedure while maintaining HADR protection by keeping a primary and a standby active.

There is always a primary to provide database service and this primary always has at least one standby providing HA and DR protection.

You should perform the update or upgrade on all of the standbys before doing so on the primary. This is particularly important if you are updating the fixpack level because HADR does not allow the primary to be at a higher fixpack level than the standby.

The procedure is essentially the same as with one standby, except you should perform the upgrade on one database at a time and starting with an auxiliary standby. For example, consider the following HADR setup:
  • host1 is the primary
  • host2 is the principal standby
  • host 3 is the auxiliary standby

Procedure

For this setup, perform the rolling update according to the following sequence:
  1. Update the auxiliary standby database on host3 by issuing the following steps:
    1. Use the DEACTIVATE DATABASE command to shut down the auxiliary standby database.
    2. If necessary, shut down the instance on the auxiliary 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 auxiliary standby database.
    5. Use the ACTIVATE DATABASE command to restart the auxiliary standby database.
    6. Ensure that the auxiliary standby has caught up with the primary. Use the MON_GET_HADR table function (on the primary or a read-enabled auxiliary standby) or the db2pd command with the -hadr option to check this.
  2. Update the principal standby database on host2 by issuing the following steps:
    1. Use the DEACTIVATE DATABASE command to shut down the principal standby database.
    2. If necessary, shut down the instance on the principal standby database.
    3. Change at least one 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 principal standby database.
    5. Use the ACTIVATE DATABASE command to restart the auxiliary standby database.
    6. Ensure that HADR enters peer state. Use the MON_GET_HADR table function (on the primary or a read-enabled principal standby) or the db2pd command with the -hadr option to check this.
  3. Switch the roles of the primary and principal standby databases:
    1. Issue the TAKEOVER HADR command on the principal standby database on host2.
    2. Direct clients to the new primary database by 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.
  4. Update the original primary database (which is now the standby database) on host1 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.