Overview

OceanBase Database supports cluster upgrades by using upgrade scripts. The entire upgrade process is transparent to applications, and no write or service stop operations are required from the application side. OceanBase Database upgrades zones in sequence. During the upgrade, the partition leader will actively switch between zones and redirect business traffic from the zone being upgraded to other zones.

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

Limitations

When you upgrade an OceanBase cluster, the following limitations apply:

• DDL operations are disabled during some stages of the upgrade and will be re-enabled after the upgrade is complete.
• The major freeze operation is disabled during some stages of the upgrade and will be re-enabled after the upgrade is complete.
• Migration replication and load balancing are disabled during some stages of the upgrade.
• Physical backup and restore operations are disabled during the upgrade.
• New tenants cannot be created during the upgrade.

Considerations

When you upgrade an OceanBase cluster, note the following considerations:

• Log archiving is disabled during the upgrade from OceanBase V4.0 to V4.1.

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

• You cannot directly upgrade an OceanBase transitional version. You must follow the upgrade version sequence specified in the oceanbase_upgrade_dep.yml file.

• The upgrade script must be executed directly on the observer process where the Root Service is located. It cannot be executed through OceanBase Database Proxy (ODP).

• The following parameters may change during the upgrade. You must back up these parameters before the upgrade:

  • server_permanent_offline_time
  • enable_rebalance
  • enable_rereplication

• Starting from OceanBase Database V4.3.0 Beta, OceanBase Database no longer supports the zlib_1.0 compression algorithm. During the upgrade, the following pre-checks are performed:

  • The zlib compression algorithm is no longer supported as the value of the log_transport_compress_func parameter. You must use another compression algorithm instead.
  • If some tables use the zlib compression algorithm, you must replace the compression algorithm with another supported one or disable compression during the upgrade.
  • The zlib compression algorithm is no longer supported as the compression algorithm for OBKV-Table connections. You must set the tableapi_transport_compress_func parameter to another compression algorithm.

• In clusters with ARM architecture or x86 architecture that does not support the AVX2 (Advanced Vector Extensions 2) instruction set, you cannot upgrade from a lower version of V4.3 (V4.3.0, V4.3.1, or V4.3.2) to V4.3.3 or later if columnstore tables have been used or modified to rowstore tables. This is to prevent data correctness risks after the upgrade.

• When a cluster of a lower version of V4.3 is upgraded to a cluster of V4.3.3 or later, a standby tenant cannot parse the logs generated by the upgraded cluster. In this case, an error is returned when the standby tenant submits logs (the error is not persisted). For more information about how to restore data, see Prepare for data restoration.

• Tenants backed up in a cluster of V4.3.2 cannot be restored in a cluster of V4.3.3.

• Starting from V4.2.5 BP3, V4.2.5 BP4, V4.2.5 BP5, V4.3.5 BP1, V4.3.5 BP2, and V4.3.5 BP3, the instruction set requirements for running in an x86 architecture environment are added. The OBServer process checks whether the current environment supports the AVX instruction set before startup. If the AVX instruction set is not supported, the OBServer process cannot start. Upgrading an OBServer process running on an x86 architecture that does not support the AVX instruction set to the above versions will result in the inability to start and roll back. Please pay attention to this.

  Note

  Starting from the following versions, the mandatory dependency on the AVX instruction set has been adjusted:

  • For V4.3.5, the AVX instruction set is no longer mandatory from V4.3.5 BP4 onwards.
  • For V4.2.5, the AVX instruction set is no longer mandatory from V4.2.5 BP6 onwards.
  • For V4.4.0, the AVX instruction set is no longer mandatory from V4.4.1 onwards.

Version compatibility

• You can upgrade from any version of V4.3.x to V4.3.5 BP5.
• You cannot upgrade from a version in the V4.2.x series or earlier to V4.3.5 BP5.
• Starting from V4.3.2, the persistence format of multi-source data has been restructured. During the upgrade, the new and old multi-source data formats must be converted. Reserve sufficient upgrade time when the number of partitions is large.
• For scenarios with continuous vector writes, index rebuilding is required.
• During the mixed deployment upgrade from V4.3.0/V4.3.1/V4.3.2 to V4.3.5 BP5, if the tenant leader is on the old node, the transfer will fail. You must upgrade to V4.3.5 BP5 to execute the transfer successfully.

Upgrade path

The following figure describes the upgrade path.

• For the V4.2.x version:

  • The V4.0.0.0, V4.1.0.0, V4.1.0.2, and V4.2.0.0 versions can be upgraded to the V4.2.1.11 version, and then to the V4.2.5.7 version.
  • The V4.2.2 and V4.2.4 versions can be directly upgraded to the V4.2.5.7 version, or first upgraded to the V4.2.5.0 to V4.2.5.6 version and then to the V4.2.5.7 version.
  • Barrier versions: V4.2.1.11, V4.2.5.7.

• For the V4.3.x version:

  • All the V4.3.x versions can be directly upgraded to the V4.3.5.5 version.
  • Upgrades from the V4.2.x series or earlier versions to the V4.3.x versions are not supported.

• For the V4.4.x version:

  • The V4.4.0, V4.4.0.1, and V4.4.1 versions can be upgraded to the V4.4.2 version.
  • The V4.2.5 BP7 version can be upgraded to the V4.4.2 version.

What to do next

Upgrade an OceanBase cluster

Reference

For more information about how to use the OceanBase Cloud Platform (OCP) to upgrade an OceanBase cluster, see Upgrade a version.