Upgrading a Db2 server in an HADR environment with down-level standby for Reads on Standby

When upgrading a Db2 11.5.8 or later High Availability Disaster Recovery (HADR) environment to Db2 12.1 or later, you can allow read-only applications to access the database by using the HADR reads on standby feature during the upgrade of the primary database. After the primary database is upgraded, the standby database can be upgraded to the new Db2 version, without the need to reinitialize HADR.

For more information on supporting read-only applications on an HADR standby database, see HADR reads on standby feature.

About this task

Important: There is a prerequisite DT259396 for using this procedure. Make sure the current Db2 11.5.8 or later version that you are running contains the fix to DT259396 before using this procedure.
Note: If you are using TLS for Primary and Standby communications, Db2 must not be in STRICT_FIPS mode when following this upgrade procedure. Ensure that the DB2AUTH registry variable does not contain the value STRICT_FIPS. For further information on the various security modes of Db2, see Security Modes in Db2.

During this procedure, the primary database is moved to the new Db2 version while the standby database is on the current version. There is no connection between the primary and the standby database while they are at different Db2 versions. Log data generated by the primary database when it is running on the new Db2 version is not shipped to the standby database, until after the standby database has been upgraded to the new Db2 version.

While being able to access the database during upgrade is a significant advantage, you need to be aware of the disadvantage of this procedure. Immediately after the primary database has completed the upgrade and is starting to provide full access to the database, the standby database needs to be upgraded. Until the standby database has completed its upgrade and catches up to the primary database to reach PEER state, there is an exposure of the high availability solution. That is, if there is an unexpected outage of the primary database, you cannot failover to the standby database to continue.

In a multiple standby environment, it is possible to use the Upgrading Db2 servers in HADR environments (without standby reinitialization) procedure for the primary and principal standby database, and this procedure for the auxiliary standby database. With this combined procedure, read-only access can be provided on the auxiliary standby during the time of upgrading the primary and principal standby, and there is no loss of high availability when full access resumes after the upgrade of the primary has completed.

This procedure maintains the database role and relies on normal log shipping and log replaying characteristics common to HADR functionality. The procedure avoids the need to stop HADR for upgrade and avoids the need to reinitialize HADR.

This procedure ensures all log data generated by the primary database on the current Db2 version has been shipped to the standby database, before allowing the primary database to be upgraded to the new Db2 version. This enforcement is through db2ckupgrade that is run during db2iupgrade or any db2ckupgrade invocation that establishes an exclusive connection to the database to do proper database consistency checking.

This procedure can be applied to HADR databases in single partition environments that use single standby or multiple standby configurations.

  • Review the system requirements for HADR. For more details, see System requirements for Db2 high availability disaster recovery (HADR).

  • If you have two HADR databases (database A 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 upgrade:

    • The primary for database A runs on system 1, and the standby runs on system 2
    • The primary for database B runs on system 2, and the standby runs on system 1
  • Ensure that you are familiar with the steps involved in upgrading a Db2 instance and Db2 databases.
  • Using High availability disaster recovery (HADR) monitoring, ensure that both the primary's log shipping functionality and the standby's log replaying functionality is working properly before running db2ckupgrade.
  • If you are using the reads on standby feature, ensure that the database configuration parameter logindexbuild is turned on, on the primary database so that index recreation that is done during upgrade is sent to the standby database for replay. This allows read connections to resume post upgrade on the standby database.
  • In case of failures during the HADR upgrade procedure, ensure that you are familiar with dealing with failures while upgrading Db2 servers in HADR environments with previous-level standby for Reads on Standby.
  • All Db2 upgrades, hardware upgrades, and software upgrades should be implemented in a test environment before being applied to your production system.

This upgrade task describes the steps to upgrade HADR databases in a single partition, single standby environment to Db2 version from 11.5.8. Both the primary and standby database should be using the same fix pack level of Db2.

Important: Each time you run the db2iupgrade command to upgrade a server, be sure to follow up by running the db2licm -a < license file > command to re-apply your Db2 license
Restriction: The primary and standby database must be on the same Db2 11.5.8 or later level containing prerequisite DT259396.

Procedure

To upgrade databases in an HADR environment to Db2 12.1 or later:

  1. Ensure that you are running on Db2 11.5.8 or later containing the prerequisite DT259396.
  2. On the primary instance, monitor the database by using the db2pd -hadr or MON_GET_HADR command to ensure that primary log shipping and standby log replay are not lagging and are functioning properly. Monitoring the HADR database, reduces the chance of failures in the upgrade process. Also, ensure that replay delay is turned off on the standby to avoid significant time delay or lag.
  3. Ensure that replay delay is turned off on all the standby databases by setting the database configuration parameter hadr_replay_delay to 0 to ensure the standby log replay position can catch up to the primary in a reasonable amount of time.
  4. On the standby instance, deactivate the database by using the DEACTIVATE DATABASE command.
  5. On the standby instance, issue db2ckupgrade -setUpgradePending to set "Upgrade pending" in standby database configuration. When in Upgrade pending state, the standby database does not terminate when the configured primary database is upgraded to the new Db2 version. This allows the standby database to stay activated to support read only applications, while the primary database is being upgraded.
  6. On the standby instance, activate the database by using the ACTIVATE DATABASE command.
  7. Switches read-only applications to run against the standby database.
  8. On the primary instance, deactivate the database by using the DEACTIVATE DATABASE command to ensure that log shipping is completed on the primary database and data is transferred to the standby database.
  9. On the primary instance, stop the Db2 instance by using db2stop command. Ensure that applications do not connect so that no new log data is generated and the log replay position on the standby database eventually matches the log shipping position on the primary database.
  10. On the primary instance, upgrade the Db2 instance by using the db2iupgrade command. The db2iupgrade command calls the db2ckupgrade command to verify that the database is ready for upgrade. The db2iupgrade does not run when the db2ckupgrade command reports errors. Check the log file if you encounter any errors. The db2ckupgrade command verifies that a valid standby database can be connected to the primary database. Once a connection is established, log shipping functionality begins and ships any pending log data, if necessary. The db2ckupgrade command also verifies that the log shipping position of the primary database matches the log replay position on the standby database.
  11. On the primary instance, issue the UPGRADE DATABASE command to upgrade the primary database. This upgrades the primary database to the new Db2 version. Logs generated by the primary database during this step are not shipped to the standby database.
  12. On the primary instance, perform post upgrade tasks, if any. Logs generated by the primary database during this step are not shipped to the standby database.
  13. On the primary instance, open the database to service applications.
  14. On the standby instance, deactivate the database by using the DEACTIVATE DATABASE.
  15. On the standby instance, stop the Db2 instance by using db2stop command.
  16. On the standby instance, upgrade the Db2 instance by using the db2iupgrade command. The db2iupgrade command calls the db2ckupgrade command to verify that the standby database is ready for upgrade.
  17. On the standby instance, issue the UPGRADE DATABASE command. This upgrades the database metadata objects. After the metadata files are upgraded, the standby database connects to the primary database to begin receiving the logs produced by the primary database starting from its execution of the UPGRADE DATABASE command.
  18. The standby database completes log catchup to reach PEER state.

What to do next

After upgrading the Db2 server, perform the recommended post-upgrade tasks such as resetting the diagnostic error level to its pre-upgrade value, adjusting log space size, and rebinding packages. In addition, verify that the upgrade of your Db2 server was successful. For more information see, Post-upgrade tasks for Db2 servers and Verifying upgrade of Db2 servers.