OceanBase Database supports cluster upgrades by using upgrade scripts. The entire upgrade process is transparent to applications, which do not need to perform any stop-write or stop-service operations on the server side. OceanBase Database upgrades clusters in the order of zones. During the upgrade, the partition leader will actively switch between zones and redirect the business traffic of the zone to be upgraded to other zones for execution.
This topic describes the upgrade limitations, considerations, and paths of OceanBase Database.
Notice
OceanBase Database does not support upgrading from V4.2.x or earlier to V4.3.x.
Limitations
When you upgrade an OceanBase cluster, note the following limitations:
- DDL operations are disabled during the upgrade. They are enabled after the upgrade is completed.
- The
major freezeoperation is disabled during the upgrade. It is enabled after the upgrade is completed. - Migration replication and load balancing are disabled during the upgrade.
- Physical backup and restore are disabled during the upgrade.
- You cannot create a new tenant during the upgrade.
Notice
If the OceanBase cluster is associated with an arbitration service, you must upgrade the arbitration service before you upgrade the OceanBase cluster. For more information, see Upgrade the arbitration service.
You can query the oceanbase.DBA_OB_ARBITRATION_SERVICE view of the system tenant to check whether the OceanBase cluster is associated with an arbitration service.
Considerations
When you upgrade an OceanBase cluster, note the following considerations:
During the upgrade from OceanBase V4.0 to V4.1, log archiving is disabled.
If you need to perform
ADD SERVERorDELETE SERVERoperations during the upgrade, contact technical support.You cannot directly upgrade from an OceanBase transitional version. You must follow the upgrade sequence specified in the
oceanbase_upgrade_dep.ymlfile.You must execute the upgrade script directly on the observer process where the Root Service is located. You cannot connect to the Root Service through OceanBase Database Proxy (ODP).
During the upgrade, the following parameters may change. You must back up these parameters before the upgrade:
Starting from OceanBase Database V4.3.0 Beta, the zlib_1.0 compression algorithm is no longer supported. During the upgrade, the following checks are performed:
- The
zlibcompression algorithm is no longer supported as the value of thelog_transport_compress_funcparameter. You must use another compression algorithm instead. - If some tables use the
zlibcompression algorithm during the upgrade, you must replace the compression algorithm with another supported one or disable compression during the upgrade. - The
zlibcompression algorithm is no longer supported for OBKV-Table connections. You must set thetableapi_transport_compress_funcparameter to another compression algorithm.
- The
In clusters with ARM architecture or x86 architecture that does not support the AVX2 (Advanced Vector Extensions 2) instruction set, if columnar tables have been used (including scenarios where columnar tables are modified to row-based tables), 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. This is to prevent data correctness risks after the upgrade.
When you upgrade a cluster of a lower version of V4.3 (V4.3.0, V4.3.1, or V4.3.2) to a cluster of V4.3.3 or later, the 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 data recovery, see Prepare for data recovery.
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 x86 architecture environments are added. Before the OBServer process starts, it checks whether the current environment supports the AVX instruction set. If the AVX instruction set is not supported, the OBServer process cannot start. Upgrading an OBServer process that does not support the AVX instruction set to one of the above versions will result in the inability to start or 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 starting from V4.3.5 BP4.
- For V4.2.5, the AVX instruction set is no longer mandatory starting from V4.2.5 BP6.
- For V4.4.0, the AVX instruction set is no longer mandatory starting from V4.4.1.
Upgrade considerations
- You can upgrade from any version of V4.3.x to V4.3.5 BP6.
- You cannot upgrade from a version of the V4.2.x series or earlier to V4.3.5 BP6.
- Starting from V4.3.2, the persistence format of multi-source data has been restructured. During the upgrade, the old and new multi-source data formats must be converted. Sufficient upgrade time must be reserved, especially 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 located on the old node, the transfer will fail. You must upgrade to V4.3.5 BP5 to execute the transfer.
Upgrade path diagram
Note
- The upgrade path diagram described in this topic applies to SN mode only. To obtain more information about the upgrade path of another version, you can refer to the
oceanbase_upgrade_dep.ymlfile, which records the upgrade topology of OceanBase Database. - After you decompress the target OceanBase RPM package, the
homeandusedirectories will be created in the RPM package storage directory. Upgrade-related scripts and theoceanbase_upgrade_dep.ymlfile will be stored in thehome/admin/oceanbase/etcdirectory.
oceanbase_upgrade_dep.yml file to obtain detailed upgrade path information. For more information, see Step 2: Confirm the upgrade process in the Upgrade OceanBase cluster topic.
The following table describes the meanings of the upgrade path diagram.
Upgrade path of V4.2.x versions:
- You can directly upgrade from the V4.0.0.0, V4.1.0.0, V4.1.0.2, or V4.2.0.0 versions to the V4.2.1.11 version and then upgrade the V4.2.1.11 version to the V4.2.5.7 version.
- You can directly upgrade from the V4.2.2 to V4.2.4 versions to the V4.2.5.7 version. You can also upgrade the V4.2.2 to V4.2.4 versions to the V4.2.5.0 to V4.2.5.6 versions first and then upgrade to the V4.2.5.7 version.
- You can directly upgrade from the V4.2.5 BP7 version to the V4.4.2 or V4.4.2.1 version.
- Barrier versions: V4.2.1.11 and V4.2.5.7.
Upgrade path of V4.3.x versions:
- You can directly upgrade any V4.3.x version to the V4.3.5.6 version.
- You can directly upgrade the V4.3.5.6 version to the V4.4.2.1 version.
- OceanBase Database of the V4.2.x series or earlier versions cannot be upgraded to the V4.3.x series.
- Barrier version: V4.3.5.6.
Upgrade path of V4.4.x versions:
- You can directly upgrade from the V4.4.0 or V4.4.1 version to the V4.4.2 or V4.4.2.1 version.
- You can directly upgrade from the V4.4.0 or V4.4.1 version to the V4.6.0 version.
Upgrade path of V4.5.x versions:
- You can directly upgrade from the V4.5.0 version to the V4.6.0 version.
What to do next
References
For information about how to use OceanBase Cloud Platform (OCP) to upgrade an OceanBase cluster, see Upgrade version.