Overview

OceanBase clusters can be upgraded by using upgrade scripts. The upgrade process is transparent to applications, so you do not need to perform any write or service suspension operations with your applications during the upgrade. OceanBase clusters are upgraded by zone. During the upgrade, the system will perform an active switchover of leader partitions among zones and route the business of the to-be-upgraded zone to other zones.

This topic describes the upgrade limitations, considerations, and paths of OceanBase Database.

Limitations

There are the following limitations on OceanBase clusters during an upgrade:

• DDL is prohibited: DDL is prohibited during some stages of the upgrade. It will be automatically enabled after the upgrade is complete.
• major freeze is prohibited: When upgrading between some versions, major compactions are prohibited. It will be automatically enabled after the upgrade is complete.
• Replication and load balancing are prohibited: When upgrading between some versions, replication and load balancing are prohibited.
• Physical backup and restore are prohibited: During an upgrade, physical baseline backups (log archives are not affected) and restores are prohibited.
• Creating tenants is prohibited.

Considerations

When upgrading an OceanBase cluster, note the following points:

• Log archiving will be interrupted during an upgrade from OceanBase Database V4.0 to V4.1.

• If the upgrade requires ADD SERVER/DELETE SERVER operations, contact the technical support team for assistance.

• OceanBase Database of earlier versions cannot be directly upgraded. Follow the upgrade sequence in the oceanbase_upgrade_dep.yml file.

• You must directly connect to the observer process where the Root Service is located to run the upgrade script. You cannot use OceanBase Database Proxy (ODP) to connect to the database.

• The following parameter changes may occur during the upgrade. Back up these parameters before the upgrade:

  • server_permanent_offline_time
  • enable_rebalance
  • enable_rereplication

• Starting from V4.2.2, OceanBase Database no longer supports the zlib_1.0 compression algorithm. The upgrade check will perform the following check before the upgrade:

• The zlib compression algorithm is no longer supported as the value of the log_transport_compress_func parameter during an upgrade. Please use another compression algorithm instead.

• If you find that some tables use the zlib compression algorithm during the upgrade, replace the compression algorithm with a supported one or disable compression.

• The zlib compression algorithm is not supported for OBKV-Table connections during an upgrade. Set the kv_transport_compress_func parameter to use a different compression algorithm.

Upgrade procedure

The upgrade scripts in OceanBase Database V4.x rely only on the Python scripts in the target version's RPM package. Specifically, if the target version is V4.1.0 or later, only one upgrade process is available, and you need only the OceanBase RPM package of the target version. After decompressing the OceanBase RPM package, you will find the oceanbase_upgrade_dep.yml file, which records the version upgrade topology of OceanBase Database.

For more information about the upgrade process, see Step 2: Verify the upgrade procedure in Upgrade an OceanBase cluster.

Upgrade notes

• OceanBase Database V4.2.1 BP2 and earlier of the V4.x series are supported to upgrade to OceanBase Database V4.2.2 online through effective upgrade paths. OceanBase Database V4.2.1 BP3 and later do not support upgrading to V4.2.2. As V4.2.1 and V4.2.x evolve in parallel, later BPs of V4.2.1 will support upgrading to later versions of V4.2.x.
• During the upgrade, the system automatically disables major compactions and DDL operations. After the upgrade is completed, the operations resume.

Next steps

References

For more information about how to upgrade an OceanBase cluster using OceanBase Cloud Platform (OCP), see Upgrade versions.