Avoiding Db2 engine pod restarts when upgrading the Db2 Operator to version 110508.0.1

Condition

After upgrading the Db2 Operator on your OpenShift cluster to version 11.5.8.0-cn1 (11058.0.1), the Db2 engine pod restarts unexpectedly. This restart can be particularly troublesome when running Db2 in an HADR configuration:

Your auxiliary standby HADR database cannot reconnect to the primary, causing you to manually restart your HADR service.
An unexpected failover to standby can occur, depending on the order in which nodes are restarted..

Cause

The LDAP service is enabled by the Db2® Operator by default. This setting causes the Db2 engine pod to restart unexpectedly.

Note: This is only an issue if you are actively using the LDAP service. If you have disabled the LDAP service then there should be no issues when upgrading the Db2 Operator. If LDAP is enabled and you are not using it, you can disable it and skip the workaround mentioned below.

Remedy

You can avoid restarts by adding an annotation that puts the engine pods in maintenance mode before the upgrade, and then returns them to normal state.

Procedure

Before upgrading the db2u-operator, set an annotation for your deployments to set the MAINTENANCESTATE to InMaintenance:
```
kubectl annotate db2ucluster $DB2UCLUSTER_ID db2u.databases.ibm.com/maintenance-pause-reconcile=true
```
Upgrade the db2u-operator to s11.5.8.0-cn1.
The Db2 pods in your OpenShift cluster remain up.

Upgrade your Db2 deployments by first changing the version for your deployments to s11.5.8.0-cn1.

oc patch db2ucluster $DB2UCLUSTER_ID --type merge -p
          '{"spec":{"version":"s11.5.8.0-cn1"}}'

Remove the annotation regarding MAINTENANCESTATE that you set in step 1.
```
kubectl annotate db2ucluster $DB2UCLUSTER_ID db2u.databases.ibm.com/maintenance-pause-reconcile-
```
Your Db2 on OpenShift cluster is now upgraded to version s11.5.8.0-cn1.