This topic describes how to upgrade an OceanBase cluster by using OCP. For more information about how to upgrade an OceanBase cluster, see Cluster upgrade in the documentation of the target version.
Prerequisites
Make sure that the current login user in the OCP console has the following permissions:
- The Cluster Maintenance resource permission.
- The Overview menu permission.
If the OceanBase cluster version is earlier than V4.0, you can upgrade it only to a version earlier than V4.0.
(Optional) If the target OceanBase version is earlier than V2.2.60, you must define an upgrade path similar to the following in the
/home/admin/ocp-server/etc/oceanbase_upgrade_dep.ymlfile of OCP. For more information, see the description at the top of the file.### The preceding content is 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 specified in the following format (including the two lines below). can_be_upgraded_to: - 2.2.74Note
The above indicates that you can upgrade OceanBase from V2.2.72, V2.2.71, V2.2.70, or any earlier version to V2.2.73, but cannot upgrade it to V2.2.74.
All required RPM packages, such as
oceanbase-x.x.x-YYYYMMDDhhmmss.el7.x86_64.rpmoroceanbase-x.x.x-YYYYMMDDhhmmss.el7.aarch64.rpm, have been uploaded.For clusters deployed in the 2F1R mode (2 full-featured replicas and 1 read-only replica), you must convert the R replica to an F replica.
You can upgrade a database to a later version only in the same mode. In standalone mode, you can upgrade it only to a later standalone database. In distributed mode, you can upgrade it only to a later distributed cluster.
When upgrading a standalone database, the LIBS dependency packages of the target version have been uploaded. For more information, see Upload a software package.
Considerations
If there are primary and standby tenants in the cluster:
If the cluster where the standby tenant is located is earlier than the current cluster version, and the primary tenant is associated with the standby tenant, we recommend that you upgrade the cluster where the standby tenant is located first to avoid data synchronization issues between the primary and standby tenants. Alternatively, you can perform a tenant daily active-standby switchover to switch the roles of the primary and standby tenants.
We recommend that you keep the cluster version of the standby tenant consistent with that of the primary tenant.
For OceanBase Database V4.2.1 and later, if you use the DBLink feature to access an Oracle database, you must install and configure OCI 12.2 on all OBServer nodes of the cluster. Additionally, if you are upgrading OceanBase Database below V4.2.1 to V4.2.1 or later, you must change the previously configured 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, note the following:
OceanBase Database 4.X only supports primary and standby tenants. We recommend that you switch the primary tenant to the same cluster before upgrading the cluster to facilitate the cluster upgrade.
OceanBase Database 2.X and 3.X only support setting the upgrade sequence of the primary cluster zones. If there is a standby cluster, it is recommended to upgrade the standby cluster first. The standby cluster will be upgraded in the default sequence and will not be stopped during the upgrade.
After the primary cluster upgrade task is initiated, you must manually confirm whether to continue with the upgrade operation before the Stop Zone step in the task process. For more information about the task process, see Manage tasks. We recommend that you complete the upgrade as soon as possible to avoid abnormal behavior that may cause cluster upgrade issues.
After the cluster is upgraded, please manually initiate a full backup for the cluster.
Procedure
Log in to the OCP console.
In the left-side navigation pane, click Cluster. The Clusters page automatically appears.
On the Clusters page, find the target cluster and click its name.
On the Overview page of the cluster, click the ... icon in the upper-right corner and select Upgrade Version.
The Upgrade Version page appears.
View the information of the OceanBase cluster to be upgraded, including
Cluster Name: Cluster ID, OceanBase version, and CPU architecture.If the target cluster is associated with primary and standby clusters, they will also be upgraded as the target clusters.
Select whether to perform minor compaction before stopping the process. This action will extend the response time for stopping the process, but can significantly shorten the OBServer restore time.
Select an upgrade mode based on your business needs.
Rolling Upgrade (recommended): This mode does not interrupt business operations during the upgrade. We recommend that you choose this mode.
Downtime Upgrade: This mode interrupts business operations during the upgrade. We recommend that you choose this mode only if you have fewer than three zones. If you choose Rolling Upgrade (recommended), the majority cannot be formed during the upgrade if you have fewer than three zones.
Select the target version for upgrading OceanBase.
If there is no RPM package for the target version in OCP, you can upload the RPM package for the target version by clicking Add Version in the drop-down list.
Note
- Stand-alone clusters support only Service Interruption Upgrade.
- You can select only a software package version later than the current version.
- After you select a software package version, the system checks whether an installation package exists for the current cluster's hardware architecture. If no installation package exists for the specified architecture, the upgrade fails.
If you select Upgrade Method, you can adjust the upgrade sequence of zones.
By default, the system upgrades the zone where the RS leader resides first, and then upgrades other zones based on the order in Zones. You can drag the zones to adjust the upgrade sequence.
Click Upgrade.
If the system returns an error message indicating that no upgrade path exists from version xxx to xxx, define an upgrade path in the
oceanbase_upgrade_dep.ymlfile as prompted.If the system returns a message indicating that the upgrade path is xxx, click OK.
On the xxx Upgrade Path Confirmation page, check whether RPM packages exist for all versions on the upgrade path. If not, click Go to Upload to upload the missing RPM package.
Click OK.
On the dialog box that appears, you can click View Tasks to view the upgrade progress.
When the task status is Complete, and the status of the cluster is Running on the Clusters page, the upgrade is successful.
Note
OCP does not support rolling back an OceanBase cluster upgrade task. Do not manually skip or roll back the task.
View the upgrade task.
During an upgrade, one main task and multiple subtasks are generated. The main task generates several subtasks based on the nodes that require a binary version upgrade, and then gradually replaces the binary files that require an upgrade.
Main task: A subtask is generated for each node that requires a binary version upgrade on the upgrade path. The subtasks are used to gradually replace the binary files that require an upgrade. The
Submit cluster upgrade taskgenerates a subtask.Wait dag successindicates that the subtask is waiting for execution to complete. The combination ofSubmit cluster upgrade taskandWait dag successmay execute multiple times. The number of executions depends on the number of nodes that require a binary version upgrade on the upgrade path.Subtask: Upgrades all OceanBase cluster versions. It mainly executes the upgrade script: precheck script, upgrade pre-script, OBServer node replacement, upgrade post-script, and version check.