Upgrade an OceanBase cluster

This topic describes how to upgrade an OceanBase cluster in the OceanBase Cloud Platform (OCP) console. The upgrade process of OceanBase Database varies based on its version. For more information about the upgrade process of a specific version, see the upgrade guide of the corresponding version in OceanBase Documentation Center.

Prerequisites

• Make sure that you have the following permissions:

  • Resource Permissions : Cluster Maintenance permission
  • Menu Permissions : Permission on the Overview menu of Clusters

• An OceanBase cluster of a version earlier than V4.0 can be upgraded only to another version earlier than V4.0.

• (Optional) To upgrade OceanBase Database earlier than V2.2.60, you must define an upgrade path in the oceanbase_upgrade_dep.yml file in the /home/admin/ocp-server/etc directory of OCP. The upgrade path is similar to the following example. The configuration method is described at the top of the file.

  ### Omitted.
  - version: 2.2.70
    can_be_upgraded_to:
        - 2.2.71
  - version: 2.2.71
    can_be_upgraded_to:
        - 2.2.72
  - version: 2.2.72
    can_be_upgraded_to:
        - 2.2.73
  - version: 2.2.73         # The target version must be exactly in this format, including the two lines below:
    can_be_upgraded_to:
        - 2.2.74
  

  Note

  The preceding example shows that OceanBase Database can be upgraded from V2.2.72, V2.2.71, V2.2.70, or earlier to V2.2.73, but not to V2.2.74.

• You have uploaded all RPM packages required for the upgrade, such as oceanbase-x.x.x-YYYYMMDDhhmmss.el7.x86_64.rpm or oceanbase-x.x.x-YYYYMMDDhhmmss.el7.aarch64.rpm.

• If the cluster is deployed with two full-featured replicas and one read-only replica, you must convert the read-only replica into a full-featured replica. Otherwise, the rotating upgrade method cannot be supported.

Considerations

• If tenants in the cluster are in primary/standby relationships:

  • If the cluster of a standby tenant associated with the primary tenant in the current cluster is of a version earlier than that of the current cluster, to avoid data synchronization exceptions between the primary and standby tenants, we recommend that you first upgrade the cluster of the standby tenant, or switch the primary tenant in the current cluster to the STANDBY role. For more information about how to perform a switchover, see Switchover.

  • We recommend that you keep the cluster versions of the primary and standby tenants the same.

• When you use a DBLink to access a remote Oracle database, if OceanBase Database is of V4.2.1 or later, you must install and configure Oracle Call Interface (OCI) 12.2 on all OBServer nodes in the cluster, and if OceanBase Database is of a version earlier than V4.2.1, you must upgrade OceanBase Database to V4.2.1 and upgrade OCI 11.2 to OCI 12.2. For more information, see Install and configure OCI.

If you choose to adjust the upgrade sequence of zones:

• OceanBase Database V4.x supports only tenant-level primary/standby databases. We recommend that you move the primary tenants to the same cluster to facilitate cluster upgrade.

• In OceanBase Database V2.x and V3.x, you can set the upgrade sequence of zones only for a primary cluster. If a standby cluster is available, the zones of the standby cluster are upgraded first based on the default sequence without interruption.

• After the task to upgrade the primary cluster is started, you need to confirm whether to continue with the upgrade before the Stop Zone process starts. For the task process, see Manage tasks. We recommend that you complete the upgrade as soon as possible to prevent any exceptions that could cause cluster upgrade issues.

Procedure

1. Log on to the OCP console.

2. In the left-side navigation pane, click Clusters . The Clusters page automatically appears.

3. On the Clusters page, find the target cluster and click its name.

4. On the Overview page of the cluster, click the More icon in the upper-right corner and select Upgrade Version .

   The Upgrade Version page appears.

   

   • Check the name, ID, OceanBase Database version, and CPU architecture of the OceanBase cluster.

     If the cluster is associated with a primary or standby cluster, the associated primary or standby cluster is also upgraded.

   • Specify whether to initiate a minor compaction before stopping the observer process. A minor compaction prolongs the response time required to stop the observer process, but significantly shortens the time required to restore the OBServer node.

   • Select an upgrade method based on your business requirements.

     • Rolling Upgrade (recommended) : Your business is not interrupted during the upgrade.

     • Downtime Upgrade : Your business is interrupted during the upgrade. Proceed with caution. If your cluster has less than three zones, the majority of zones cannot be formed in rolling upgrade. In this case, we recommend the downtime upgrade method.

   • Select the target OceanBase Database version from the drop-down list of the Upgrade Version parameter.

     If the RPM package for the target version does not exist in the list, you can click Add Version at the bottom of the list to upload the target RPM package.

     Note

     • A standalone centralized database supports only the Downtime Upgrade method.
     • You can select only a version that is later than the current version.
     • After you select a version, the system checks whether the installation package for the hardware architecture of the current cluster exists. If not, the upgrade cannot be performed.

   • If you select the Rolling Upgrade method, you can adjust the upgrade sequence of zones.

     By default, the zone where the RootService leader exists is upgraded first, and other zones are upgraded based on the sequence in the zone list on the Overview page of the cluster. You can drag a zone to adjust the upgrade sequence.

5. Click Upgrade .

   • If an error message is displayed prompting that the upgrade path from the source version to the specified target version is not found, you must define the upgrade path in the oceanbase_upgrade_dep.yml file as described in the "Prerequisites" section of this topic.

   • If the configurations are correct, a dialog box automatically appears, prompting you to confirm the upgrade path.

     In the dialog box, verify whether the RPM packages exist for all the specified versions. If not, click Upload to upload the RPM packages as required.

6. Click OK .

   In the dialog box that appears, you can click View Task to view the upgrade progress.

   When the task enters the Completed state, and the status of the cluster is displayed as Running in the Clusters page, the cluster is upgraded.

   Notice

   OCP does not allow you to roll back the upgrade of an OceanBase cluster. Do not manually skip any upgrade steps or roll back the upgrade.

7. View the upgrade task.

   The upgrade task is divided into multiple subtasks based on the upgrade nodes.

   • In the upgrade task, each upgrade node whose binary file needs to be replaced along the upgrade path is handled by a subtask. As shown in the following figure, Submit cluster upgrade task indicates that a subtask is created, and Wait dag success indicates that the system is waiting for the subtask to complete. Submit cluster upgrade task and Wait dag success come in pairs and may appear many times. The number of occurrences depends on that of upgrade nodes where the binary files are replaced.

   • After all the subtasks are completed, the OceanBase cluster is upgraded to the target version. Subtasks execute a range of upgrade scripts, such as precheck script, pre-upgrade script, OBServer node replacement script, post-upgrade script, and version check script.