Upgrading Db2 Big SQL

Verifying that the upgrade completed successfully

When the upgrade is complete and successful, the following message is displayed at regular intervals in the Db2 Big SQL head pod log:

head_pod=$(oc get pod -l app=db2-bigsql,instance=$INST_ID,bigsql-node-role=head --no-headers=true -o custom-columns=POD:.metadata.name)
oc logs -f $head_pod

[...]

Upgrade completed successfully.  Big SQL service is ready for use

To confirm that the upgrade was successful and the cluster is operational, run a smoke test:

head_pod=$(oc get pod -l app=db2-bigsql,instance=$INST_ID,bigsql-node-role=head --no-headers=true -o custom-columns=POD:.metadata.name)

# If connected to a Hadoop cluster 
oc exec -it $head_pod -- bash -lc '/usr/ibmpacks/IBM-Big_SQL/current/bigsql-cli/bigsql-admin -smoke

# If connected exclusively to an Object Store service, you must provide the name of a bucket that exists on the storage service to execute the smoke test
oc exec -it $head_pod -- bash -lc '/usr/ibmpacks/IBM-Big_SQL/current/bigsql-cli/bigsql-admin -smoke -o <bucket-name>

To further validate the operational state of the cluster, you can connect an application or JDBC client to it to execute workloads. However, you must first disable access to the previous Db2 Big SQL instance and enable access to the newly installed one. Note that you are only disabling access to the previous instance. The instance itself and the data it holds remain in the cluster.

To disable access over JDBC to the previous Db2 Big SQL instance, run the following command:

oc delete service bigsql-jdbc

Then enable access to the new instance. You can now connect to the new instance to run workloads.

Retrying the upgrade

If the upgrade fails, and after an analysis of the failure and a corrective step was taken, it is possible to re-initiate the upgrade process by restarting all the pods for the new Db2 Big SQL instance. The following command deletes those pods, which will then be recreated and restarted by the Red Hat OpenShift platform:

oc delete pods -n Project -l app=db2-bigsql,instance=$INST_ID

It is also possible, but more time consuming, to delete the new Db2 Big SQL instance, create a new one as described in step 1 of the Procedure, and resume the upgrade procedure at step 2.

In both cases, the preexisting Db2 Big SQL v6.0.0 deployment is unmodified, and acts as a backup from which the upgrade process can be initiated as many times as needed.

Checking for available patches

Determine whether there are any patches available the version of Db2 Big SQL that you installed:

Clusters connected to the internet

Run the following command to check for patches:

./cpd-cli status \
--repo ./repo.yaml \
--namespace Project \ 
--assembly big-sql \
--patches \
--available-updates 

Air-gapped clusters

See the list of Available patches for Db2 Big SQL.

If you need to apply patches to the service, follow the guidance in Applying a Db2 Big SQL patch.

What to do next

Clean up the following resources.

• Delete compute and network resources.

  After validating that the upgraded instance is operational, you can delete the previous instance to free up resources on the cluster.

  Note: This action deletes all compute (pod, deployments, StatefulSets, and so on) and network resources (services) associated with the instance. If the recommended step to mark them for retention was not applied, this action also deletes the storage resources that contain the instance data. If marked for retention, the PV resource bigsql-engine is not cleaned up, and you can keep it as a backup after the previous Db2 Big SQL instance is deleted.
• Clean up PVs.

  If you decide to delete the PVs that holds the previous instance data, you can run the following command to identify the PV to delete:

  # Returns the list of existing PersistentVolume and the name of the PVC that created them
  oc get pv -o custom-columns=NAME:.metadata.name,PVC:.spec.claimRef.name

  You can then delete the PVs that were created by deleting the following Persistent Volume Claims (PVCs) with the oc delete command:

  • bigsql-engine for the head PV
  • bigsql-worker-<number> for the worker PVs

  For example:

  # List the PVs and associated PVCs
  [root@svtpe-inf ~]# oc get pv -o custom-columns=NAME:.metadata.name,PVC:.spec.claimRef.name
  NAME                                       PVC
  pvc-04e91750-9f59-40e7-b077-f878120a5ba4   bigsql-engine
  pvc-05cd31c7-3770-4dca-b274-ea794cd8b239   bigsql-worker-0
  pvc-07bd3f57-aa7e-4736-9f27-cae3d63ce3e7   bigsql-worker-1
  
  # Delete the relevant PVs
  [root@svtpe-inf ~]# oc delete pv pvc-04e91750-9f59-40e7-b077-f878120a5ba4 
  PersistentVolume pvc-04e91750-9f59-40e7-b077-f878120a5ba4 deleted
  [root@svtpe-inf ~]# oc delete pv pvc-05cd31c7-3770-4dca-b274-ea794cd8b239 
  PersistentVolume pvc-05cd31c7-3770-4dca-b274-ea794cd8b239 deleted
  [root@svtpe-inf ~]# oc delete pv pvc-07bd3f57-aa7e-4736-9f27-cae3d63ce3e7 
  PersistentVolume pvc-07bd3f57-aa7e-4736-9f27-cae3d63ce3e7 deleted

Following the upgrade, it is likely that the JDBC or JDBC-TLS port changed. To change the port back to the original port number, do the following steps:

1. Log in to your OpenShift cluster as a project administrator:

   oc login OpenShift_URL:port

2. Change to the project where the Cloud Pak for Data control plane is installed:

   oc project Project

3. Check that the original port number isn't currently in use by another service by running the following command on a node (for example, a master or infrastructure node) in the cluster.

   netstat -nap | grep <original-port-number>

4. Create a cpd-cli profile.

   To manage Db2 Big SQL instances (by running the cpd-cli service-instance command), you must create a cpd-cli profile. The profile must be set up with the identity of a user that was granted access to the Db2 Big SQL instance. For more information about creating a cpd-cli profile, see Creating a profile to use the cpd-cli management commands.

5. Identify the Db2 Big SQL instance ID.

   ./cpd-cli service-instance list --service-type bigsql --profile <profile-name>

6. Back up the current JDBC service definition, replacing <instanceid> with the Db2 Big SQL instance ID that you obtained in the previous step.

   oc get services bigsql-<instanceid>-jdbc -o yaml > bigsql_service_bak.yaml

7. Make one of the following changes to the JDBC service definition.

   oc edit service bigsql-<instanceid>-jdbc

   • Change

     - name: jdbc
       nodePort: <current-port-number>

     to

     - name: jdbc
       nodePort: <original-port-number>

   • Or change

     - name: jdbc-tls
       nodePort: <current-port-number>

     to

     - name: jdbc-tls
       nodePort: <original-port-number>

8. After the pod restarts, make sure that it is now listening on the original port.

   netstat -nap | grep <original-port-number>

9. Try a remote JDBC connection on the original port.