Upgrading Db2 servers in HADR pureScale environments (without standby reinitialization)

To upgrade pureScale databases in an HADR environment to Db2 version 11.5:

1. In a supported Db2 version 10.5 Fix Pack, 11.1 Fix Pack or later, using High availability disaster recovery (HADR) monitoring ensure that each primary member's log shipping functionality and the standby's log replay functionality are working properly.
2. Ensure that replay delay is turned off on the standby database 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.
3. On the primary instance, deactivate all databases and stop the instance. Ensure that the standby database is active.
4. Upgrade the primary instance using Upgrading Db2 pureScale instances. As part of upgrading the instance, db2iupgrade calls db2ckupgrade and for each HADR database this validates the log positions between all primary members and the standby. If the log positions do not match for some database, then db2iupgrade/db2ckupgrade fails. If this happens, ensure the log shipping/replay functionality is still healthy for that database. If healthy, increase the hadr_timeout value for that database to give the log validation check more time for the log positions to match. If there are issues getting the log positions to match then, you must proceed by stopping HADR on that database. That database needs to be upgraded then HADR reinitialized.
5. On the standby instance, deactivate all databases and stop the instance.
6. Upgrade the standby instance using Upgrading Db2 pureScale instances.
7. For each database in the standby instance, issue the UPGRADE DATABASE command on a single member. This upgrades the database metadata objects for all members and if log validation succeeded in the earlier steps the standby starts up and wait for a connection from the primary. The replay functionality begins in the background and wait for upgrade log data to be sent by the primary. At this point, the standby is considered upgrade in progress and the UPGRADE DATABASE command returns with:

   SQL1103W  The UPGRADE DATABASE command was completed successfully.

   No user connections will be allowed while in this upgrade in progress state. The progress on the standby database can be monitored by using db2pd -hadr with the Db2 diagnostics log. Connect attempts can also be issued and will receive SQL1776N, reason code 9 as long as the standby is in upgrade in progress state.
8. For each database in the primary instance, issue the UPGRADE DATABASE command on a single member. This upgrades the database metadata objects for all members and if log validation succeeded in the earlier steps attempt to form a connection with the standby database. Upgrade will not be able to proceed unless a connection to a valid standby database is available. Normal upgrade processing takes place and all log data will be shipped to the standby database for replay.
9. When upgrade on the primary database is complete the database can be activated and normal operations can resume across all members.
10. When the standby database has replayed all the upgrade log data, the standby is no longer considered in upgrade in progress state and stays activated and can resume normal operations.