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).
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
and 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
9.7 to Version 10.1.
You
cannot use this procedure to update the DB2 HADR
configuration parameters. Updates to HADR configuration parameters
should be made separately. Because HADR requires the parameters on
the primary and standby to be the same, this might require both the
primary and standby databases to be deactivated and updated at the
same time.
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 db2updv10 only
on the primary database. After running the db2updv10 command,
you might have to restart the database for changes from db2updv10 command
to take effect. To perform a restart:
- 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.