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
You have the permission to manage 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.ymlfile in the/home/admin/ocp-server/etcdirectory 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.74Note
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.rpmoroceanbase-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.
Procedure
Log on to the OCP console.
In the left-side navigation pane, click Clusters. The Cluster List tab automatically appears.
On the Cluster List page, find the target cluster and click its name.
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.
The Cluster parameter displays the OceanBase cluster to be upgraded.
If the cluster is associated with a primary or standby cluster, the associated primary or standby cluster is also upgraded.
Set the Upgrade Method parameter based on your business requirements. Valid values of this parameter:
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 database supports only the Downtime Upgrade mode.
- 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.
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 first define the upgrade path in the
oceanbase_upgrade_dep.ymlfile 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.
Click OK.
In the dialog box that appears, you can click View Task to view the upgrade progress.
If the task status is Completed, and this cluster in the cluster list on the Cluster List page is in the Running state, the cluster is successfully 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.
View upgrade tasks.
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 taskindicates that a subtask is created, andWait dag successindicates that the system is waiting for the subtask to complete.Submit cluster upgrade taskandWait dag successcome 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 the following upgrade scripts: precheck script, pre-upgrade script, OBServer node replacement script, post-upgrade script, and version check script.