Upgrade the arbitration service

This topic describes how to upgrade the arbitration service by using the command line.

Limitations

If an OceanBase cluster is associated with this arbitration service, the following limitations apply:

• When upgrading the version of an OceanBase cluster, you must first upgrade the arbitration service to a compatible version.

• You must ensure that the new version is compatible with all associated clusters. To determine compatibility between two versions, refer to the oceanbase_upgrade_dep.yml file. For example, if version A's can_be_upgraded_to attribute is version B (where B's version number is greater than A's), it indicates that version B is compatible with version A. Consequently, the arbitration service for version B is also compatible with the OceanBase cluster of version A. For more information about the oceanbase_upgrade_dep.yml file, see Step 1: Analyze the oceanbase_upgrade_dep.yml file in Upgrade an OceanBase cluster.

Procedure

Step 1: Confirm the upgrade process

Please refer to the Step 1: Analyze the oceanbase_upgrade_dep.yml file section in Upgrade an OceanBase cluster of OceanBase Database documentation to confirm the upgrade sequence from the current version to the target version. The upgrade process is determined based on the upgrade sequence as follows:

• If there are barrier versions between the current version and the target version, the upgrade process is as follows:

  1. Upgrade the arbitration service to the barrier version.
  2. (Optional) If any OceanBase clusters are associated with this arbitration service, upgrade all associated OceanBase clusters to the barrier version.
  3. If there are other barrier versions after this, repeat steps 1 and 2 until the arbitration service and all associated OceanBase clusters are upgraded to the barrier version before the target version.
  4. Upgrade the arbitration service to the target version.
  5. Upgrade all OceanBase clusters associated with this arbitration service to the target version.

• If there are no barrier versions between the current version and the target version, the upgrade process is as follows:

  1. Upgrade the arbitration service to the target version.
  2. (Optional) If any OceanBase clusters are associated with this arbitration service, upgrade all associated OceanBase clusters to the target version.

Example:

Assume the upgrade sequence is as follows:

• V4.1.0.0-100000982023031415 > V4.1.0.0 > V4.1.0.1(barrier) > V4.2.0.0
• V4.1.0.0 > V4.1.0.1 > V4.2.0.0
• V4.3.0.0 > V4.3.0.1 > V4.3.1.0

The following example describes the upgrade process for an OceanBase cluster with two replicas and an arbitration service:

• If the upgrade path contains barrier versions, and the current version is V4.1.0.0-100000982023031415, the upgrade process is as follows:

  1. Upgrade the arbitration service from V4.1.0.0-100000982023031415 to V4.1.0.1 (barrier).
  2. Upgrade the OceanBase cluster from V4.1.0.0-100000982023031415 to V4.1.0.1 (barrier).
  3. Upgrade the arbitration service to the target version V4.2.0.0.
  4. Upgrade the OceanBase cluster to the target version V4.2.0.0.

• If the upgrade path does not contain barrier versions, and the current version is V4.3.0.0, the upgrade process is as follows:

  1. Upgrade the arbitration service to the target version V4.3.1.0.
  2. Upgrade the OceanBase cluster to the target version V4.3.1.0.

(Optional) Step 2: Confirm whether there are degraded log streams in the associated OceanBase clusters

If the arbitration service being upgraded is not associated with any OceanBase clusters, you can skip this step.

Before upgrading the arbitration service, confirm that all associated OceanBase clusters do not have degraded log streams. If there are degraded log streams, you cannot execute the upgrade, which may lead to a leaderless state.

Execute the following SQL statement as the sys tenant to check for degraded log streams. If the result is not empty, it indicates the presence of degraded log streams, and you need to stop the upgrade process.

SELECT tenant_id,ls_id FROM GV$OB_LOG_STAT WHERE role = 'LEADER' AND degraded_list != "";

Step 3: Upload and install the target RPM package

1. Use the scp command to upload the OceanBase RPM package to the arbitration server node.

   scp $rpm_name admin@$observer_ip:/$rpm_dir
   

   Parameter explanation:

   • $rpm_name: the name of the RPM package.
   • $observer_ip: the IP address of the arbitration server node.
   • $rpm_dir: the directory where the RPM package is stored.

   Example:

   scp oceanbase-4.2.0.0-100010022023081911.el7.x86_64.rpm admin@10.10.10.1:/home/admin/rpm
   

2. Install the OceanBase RPM package by executing the following command:

   Notice

   If the upgrade path contains multiple barrier versions, install and upgrade each barrier version in sequence until the last barrier version is successfully upgraded, and then install the target version's RPM package.

   rpm -Uvh $rpm_name
   

   Here, $rpm_name specifies the name of the RPM package.

Step 4: Upgrade the arbitration service

1. Log in to the arbitration server.

2. (Optional) Switch to the admin user.

   If you have logged in as the admin user, you can skip this step.

   Example:

   [root@xxx /home/admin/oceanbase/etc]# su - admin
   

3. Execute the following command to view and obtain the process ID of the node.

   ps -ef | grep observer | grep -v grep
   

   Example:

   -bash-4.2$ ps -ef | grep observer | grep -v grep
   admin    103364      1 99  2022 ?        51-17:24:41 /home/admin/oceanbase/bin/observer
   

4. Execute the following command to stop the arbitration server process.

   kill -9 $pid
   

   Here, $pid specifies the process ID of the arbitration server.

   Example:

   -bash-4.2$ kill -9 103364
   

5. Execute the following command to restart the arbitration server process.

   -bash-4.2$ cd /home/admin/oceanbase && /home/admin/oceanbase/bin/observer
   

   Note

   When you restart the arbitration server process, you do not need to specify the startup parameters because the previous startup parameters are already written to the parameter file.

(Optional) Step 5: Upgrade the OceanBase cluster

If the arbitration service being upgraded is not associated with any OceanBase clusters, you can skip this step.

For more information about how to upgrade the OceanBase cluster, see Upgrade an OceanBase cluster.

References

• If you are using OceanBase Cloud Platform (OCP) to manage the OceanBase cluster and arbitration service, you can directly execute the upgrade process on the relevant operation interface as prompted. For more information, see Upgrade version and Upgrade arbitration service.
• For more information about how to upgrade the OceanBase cluster, see Overview.