Use this procedure in a high availability
disaster recovery (HADR) environment when you upgrade software or
hardware, update 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.
Before you begin
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 upgrade. 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.
The HADR pair should be in peer
state before starting 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.1 to Version 10.5.
Procedure
To perform a rolling update in an HADR environment:
- Update the standby database by issuing
the following steps:
- Use the DEACTIVATE DATABASE command
to shut down the standby database.
- If necessary, shut down the instance on the standby
database.
- 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.
- If necessary, restart the instance on the standby database.
- Use the ACTIVATE DATABASE command to restart
the standby database.
- 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:
- Issue the TAKEOVER HADR command on
the standby database.
- Direct clients to the new primary database. This can
be done using automatic client reroute.
Note: Because the
standby database takes over as the primary database, the new primary
database is now updated. If you are applying a DB2 fix
pack, the TAKEOVER HADR command changes the role
of the original primary database to standby database. However, the
command does not let the new standby database connect to the newly
updated primary database. Because the new standby database uses an
older version of the DB2 database
system, it might not understand the new log records generated by the
updated primary database, and it will be shut down. In order for the
new standby database to reconnect with the new primary database (that
is, for the HADR pair to reform), the new standby database must also
be updated.
- 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.
- Enable the HADR reads on standby
feature on the standby database as follows:
- Set the DB2_HADR_ROS registry variable to ON on
the standby database.
- Use the DEACTIVATE DATABASE command to shut
down the standby database.
- Restart the instance on the standby database.
- Use the ACTIVATE DATABASE command to restart
the standby database.
- 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 database
as follows:
- Issue the TAKEOVER HADR command on the standby
database.
- Direct clients to the new primary database.
- 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 db2updv105 only on the primary database. After running the db2updv105 command, you might have to restart the
database for changes from db2updv105 command to take effect. To perform a
restart:
Attention: db2updv105
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.
- Restart the standby database by deactivating and reactivating it. The standby database is restarted to prevent the disruption of primary database service.
- Run the following command on the standby
database:
DEACTIVATE
db dbname
where
dbname is the name of the standby database.
- Run the following command on the standby
database:
ACTIVATE
db dbname
where dbname
is the name of the standby database.
- Switch the roles of the primary and standby databases:
- Run the following command on the standby
database:
TAKEOVER
hadr on db dbname
where
dbname is the name of the standby database.
- 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.
- Restart the standby database (formerly the primary database), using the same method as in Step
1.
- 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.