Upgrading your Db2
version 10.5 Fix Pack 7 or later databases to Db2
version 11.5 in a multiple standby environment is similar to the upgrade procedure for a
single standby. 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 reduces the window where no standby database exists and
eliminates the cost of sending a backup image to all standby sites
for reinitialization.
With multiple standby databases, you also have the added flexibility of upgrading all standby
databases together to Db2
version 11.5 or leaving some auxiliary standby database at Db2
version 10.5 Fix Pack 7 or later until the primary and principal standby have completed the
upgrade procedure in case of upgrade complications.
Before you begin
Ensure that you are familiar with the following tasks:
About this task
This topic explains both upgrade options available to multiple
standby environments.
Procedure
-
Method 1: Upgrading all standbys together to Db2
version 11.5.
- In Db2
version 10.5 Fix Pack 7 or later, using High availability disaster
recovery (HADR) monitoring ensure that the primary database's log shipping functionality and
all the standby database's log replay functionality are healthy.
- 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.
- On the primary instance, deactivate all databases and stop the instance. Ensure that the standby
database is active.
- Upgrade the primary instance using db2iupgrade.
db2iupgrade calls db2ckupgrade and for HADR databases this
validates the log positions between the primary database and all standby databases. 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 some standby is unable to catch up to the primary within enough time, then
remove that standby from the hadr_target_list. The removed standby database
needs to reinitialized post upgrade using a backup image. For a given database, if there are issues
getting the log positions to match for principal and auxiliary standbys then you must proceed by
stopping HADR on that database. That database needs to be upgraded then HADR reinitialized.
- On the standby instances, deactivate all databases and stop the instance. This can be done
across all instances in parallel.
- Upgrade the standby instances using db2iupgrade. This can be done across all
instances in parallel.
- For each database in the standby instances, starting with the principal standby, issue the
UPGRADE DATABASE command. This upgrades the database metadata objects and if log
validation succeeded in the earlier steps, the principal standby starts up and waits for a
connection from the primary. The replay functionality begins in the background and waits for upgrade
log data to be sent by the primary. At this point, the principal standby is considered upgrade in
progress and the UPGRADE DATABASE command will return
with:
SQL1103W The UPGRADE DATABASE command was completed successfully.
No
user connections are allowed while in this upgrade in progress state. The progress on the standby
database can be monitored using db2pd -hadr with the Db2 diagnostics log.
Connect attempts can also be issued and receives SQL1776N, reason code 9 as long as the standby is
in upgrade in progress state.You can repeat the same step for each auxiliary standby whenever
convenient for you. The key is that the principal standby is brought up first and sits waiting for
the primary before any auxiliary can issue the UPGRADE DATABASE command.
- For each database in the primary instance, issue the UPGRADE DATABASE
command. This upgrades the database metadata objects and if log validation succeeded in the earlier
steps, attempts to form a connection with the principal standby database. Upgrade will not be able
to proceed unless a connection to a valid principal standby database is available. Normal upgrade
processing takes place and all log data are shipped to the principal standby database for replay. At
any point once the primary is able to form a connection with an auxiliary database, log data is
shipped to the auxiliary database for replay.
- When upgrade on the primary database is complete the database can be activated and normal
operations can resume.
- When a 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. For
standby databases enabled for reads on standby that means read only connections can take place
again.
-
Method 2: Leaving some auxiliary standby database at Db2
version 10.5 Fix Pack 7 or later until the primary and principal standby have completed the
upgrade procedure
- Follow steps (a) through (e) under Method 1.
Note: It is very important to deactivate the
auxiliary standby databases that you want to perform the upgrade procedure later, and keep them
deactivated while performing the upgrade of the principal standby and the primary database. Failing
to do so will result in not being able to complete the upgrade procedure later for the auxiliary
database and require them to be reinitialized.
- Upgrade the principal standby instance using db2iupgrade.
- For each database in the principal standby instance, issue the UPGRADE
DATABASE command. This upgrades the database metadata objects and if log validation
succeeded in the earlier steps, the principal standby starts up and waits for a connection from the
primary. The replay functionality begins in the background and waits for upgrade log data to be sent
by the primary. At this point, the principal standby is considered upgrade in progress and the
UPGRADE DATABASE command returns
with:
SQL1103W The UPGRADE DATABASE command was completed successfully.
No
user connections are allowed while in this upgrade in progress state. The progress on the standby
database can be monitored using db2pd -hadr in conjunction with the Db2 diagnostics log.
Connect attempts can also be issued and receive SQL1776N, reason code 9 as long as the standby is in
upgrade in progress state.
- For each database in the primary instance, issue the UPGRADE DATABASE
command. This upgrades the database metadata objects and if log validation succeeded in the earlier
steps, attempts to form a connection with the principal standby database. Upgrade will not be able
to proceed unless a connection to a valid principal standby database is available. Normal upgrade
processing takes place and all log data are shipped to the principal standby database for
replay.
- When upgrade on the primary database is complete the database can be activated and normal
operations can resume.
- When a 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. For
standby databases enabled for reads on standby that means read only connections can take place
again.
- After confirming that everything is functioning as expected on both the primary and principal
standby databases, you can repeat steps (b), (c) and (f) for each auxiliary database to upgrade them
to Db2
version 11.5.
What to do next
Post upgrade, follow the same recommendations as outlined
in Upgrading Db2 servers in HADR environments (without standby reinitialization).