OceanBase Database supports cluster upgrades by using upgrade scripts. The entire upgrade process is transparent to applications, and no write or service stoppage operations are required on the server side. OceanBase Database upgrades zones in sequence. During the upgrade, partition leaders will actively switch between zones and redirect business traffic from the zone being upgraded to other zones.
This topic describes the limitations, considerations, and upgrade paths of OceanBase Database.
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. No physical baseline backup is initiated during the upgrade (log archiving continues), and no physical restore is performed.
- You cannot create a new tenant during the upgrade.
Notice
If the cluster is associated with an arbitration service, you must upgrade the arbitration service before you upgrade the cluster. For more information about how to upgrade the arbitration service, see Upgrade the arbitration service.
You can query the oceanbase.DBA_OB_ARBITRATION_SERVICE view in the sys tenant to check whether the 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 stopped.
If the upgrade requires
ADD SERVERorDELETE SERVERoperations, contact technical support.You cannot directly upgrade an OceanBase transitional version. You must follow the upgrade sequence specified in the
oceanbase_upgrade_dep.ymlfile.You must directly connect to the observer process that hosts the Root Service to run the upgrade script. You cannot use OceanBase Database Proxy (ODP) to connect.
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 pre-checks are performed:
- The use of the
zlibcompression algorithm as thelog_transport_compress_funcparameter is no longer supported. 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 use of
zlibas the compression algorithm for OBKV-Table connections is not allowed. You must set thetableapi_transport_compress_funcparameter to another compression algorithm.
- The use of the
When you upgrade a V4.3 cluster of a version lower than V4.3.3 to V4.3.3 or later, the standby tenant of the lower version cannot parse the logs generated by the higher version 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 restore.
Tenants backed up in a V4.3.2 cluster cannot be restored in a V4.3.3 cluster.
You cannot upgrade to V4.3.3 if you have V4.3.2 backups (V4.3.2 backups cannot be restored in V4.3.3).
If the following error is returned during the pre-check for the upgrade to V4.4.2:
tenant has sys table with progressive_merge_round=1: tenant_id xxx table_ids 'xxx'- If the current version is V4.2.5 BP7, you must upgrade it to V4.2.5 BP7 hotfix3 or later before you upgrade it to V4.4.2.
- If the current version is V4.3.5 BP2 or earlier, the upgrade to V4.4.2 is temporarily not supported.
Upgrade instructions
- You can smoothly upgrade an OceanBase cluster in Shared-Nothing (SN) mode from V4.2.5, V4.2.5 BP1 to V4.2.5 BP6 to V4.2.5 BP7, and then to V4.4.2 BP1.
- You can smoothly upgrade an OceanBase cluster in Shared-Nothing (SN) mode from V4.3.5, V4.3.5 BP1 to V4.3.5 BP5 to V4.3.5 BP6, and then to V4.4.2 BP1.
- You can smoothly upgrade an OceanBase cluster in Shared-Nothing (SN) mode from V4.4.0 or V4.4.1 to V4.4.2 BP1.
Upgrade path
Note
- The upgrade path shown in this topic is applicable only to the shared nothing mode. For more information about the upgrade path for other versions, see the
oceanbase_upgrade_dep.ymlfile, which records the OceanBase version upgrade topology. - After you decompress the OceanBase RPM package of the target version, two directories named
homeanduseare generated in the directory that stores the RPM package. The related upgrade scripts and theoceanbase_upgrade_dep.ymlfile are stored in thehome/admin/oceanbase/etcdirectory.
oceanbase_upgrade_dep.yml file to verify the upgrade path. For more information, see Step 2: Confirm the upgrade process in Upgrade an OceanBase cluster.
The upgrade path diagram is explained as follows:
V4.2.x upgrade path:
- V4.0.0.0/V4.1.0.0-V4.1.0.2/V4.2.0.0 can be upgraded to V4.2.1.11 and then to V4.2.5.7.
- V4.2.2-V4.2.4 can be directly upgraded to V4.2.5.7, or can be first upgraded to V4.2.5.0-V4.2.5.6 and then to V4.2.5.7.
- V4.2.5 BP7 can be directly upgraded to V4.4.2 or V4.4.2.1.
- Barrier version: V4.2.1.11, V4.2.5.7.
V4.3.x upgrade path:
- All V4.3.x versions can be directly upgraded to V4.3.5.6.
- V4.3.5.6 can be upgraded to V4.4.2.1.
- The V4.2.x database or a lower version cannot be upgraded to V4.3.x.
- Barrier version: V4.3.5.6.
V4.4.x upgrade path:
- V4.4.0/V4.4.1 can be directly upgraded to V4.4.2 or V4.4.2.1.
- V4.4.0/V4.4.1 can be directly upgraded to V4.6.0.
V4.5.x upgrade path:
- V4.5.0 can be upgraded to V4.6.0.
What to do next
References
For more information about how to upgrade an OceanBase cluster by using OceanBase Cloud Platform (OCP), see Upgrade an OceanBase cluster.