Upgrade a cluster

This topic describes how to upgrade an OceanBase cluster that is deployed by using ob-operator.

Prerequisites

Before you upgrade a cluster, make sure that the cluster is in the Ready state. To ensure that the cluster is available during the upgrade, the cluster must have at least three zones and each tenant has at least three replicas.

Procedure

Take the ob-test cluster in the obcluster namespace as an example.

Modify the tag setting in spec

• Modify the custom resource of the OceanBase cluster.

  kubectl edit obcluster/ob-test -n obcluster
  

  If you run the preceding command, an editing interface is displayed. You can edit the custom resources in a way same as in the vi editor. When you save the modification of the tag field, an upgrade is triggered.

  spec:
    clusterID: 1
    imageObagent: oceanbase/obagent:1.2.0
    imageRepo: oceanbasedev/oceanbase-cn
    resources:
      cpu: "2"
      memory: 10Gi
      storage:
      - name: data-file
        size: 50Gi
        storageClassName: local-path
      - name: data-log
        size: 50Gi
        storageClassName: local-path
      - name: log
        size: 30Gi
        storageClassName: local-path
      - name: obagent-conf-file
        size: 1Gi
        storageClassName: local-path
    tag: v4.1.0.0-100000192023032010  ## Change the value to the tag of the image to be upgraded to.
    topology:
    - cluster: cn
      parameters:
      - name: log_disk_size
        value: 40G
      zone:
      - name: zone1
        nodeSelector:
          ob.zone1: zone1
        region: region1
        replicas: 1
      - name: zone2
        nodeSelector:
          ob.zone2: zone2
        region: region1
        replicas: 1
      - name: zone3
        nodeSelector:
          ob.zone3: zone3
        region: region1
        replicas: 1
  

• Modify the configuration file

  If the configuration file for deploying the OceanBase cluster exists, you can directly edit the tag field in the spec section in the configuration file and save the file. Then, run the following command to make the configuration take effect. The following command uses the configuration file obcluster.yaml as an example.

  kubectl apply -f obcluster.yaml
  

Verify the upgrade

• Run the following command to view the status of the custom resource in the YAML format:

  kubectl get obcluster ob-test -n obcluster -o yaml
  

  When the status field changes back to Ready, the cluster is upgraded and runs normally.

  status:
    status: Ready
    topology:
    - cluster: cn
      clusterStatus: Ready
      lastTransitionTime: "2023-07-12T08:46:16Z"
      zone:
      - availableReplicas: 1
        expectedReplicas: 1
        name: zone1
        region: region1
        zoneStatus: Ready
      - availableReplicas: 1
        expectedReplicas: 1
        name: zone2
        region: region1
        zoneStatus: Ready
      - availableReplicas: 1
        expectedReplicas: 1
        name: zone3
        region: region1
        zoneStatus: Ready
  

• Log on to the cluster to view the version.

  Check the build_version field in the oceanbase.DBA_OB_SERVERS view and the min_observer_version parameter. If the version is as expected, the upgrade is successful.

  For more information about the oceanbase.DBA_OB_SERVERS view and the min_observer_version parameter, see oceanbase.DBA_OB_SERVERS and min_observer_version.

  obclient> SELECT SVR_IP,ZONE,STATUS,BUILD_VERSION FROM  oceanbase.DBA_OB_SERVERS;
  

  The returned result is as follows:

  +-----------------+-------+--------+-------------------------------------------------------------------------------------------+
  | SVR_IP          | ZONE  | STATUS | BUILD_VERSION                                                                             |
  +-----------------+-------+--------+-------------------------------------------------------------------------------------------+
  | xxx.xxx.xxx.xxx | zone3 | ACTIVE | 4.1.0.0_100000192023032010-0265dfc6d00ff4f0ff4ad2710504a18962abaef6(Mar 20 2023 10:12:05) |
  | xxx.xxx.xxx.xxx | zone1 | ACTIVE | 4.1.0.0_100000192023032010-0265dfc6d00ff4f0ff4ad2710504a18962abaef6(Mar 20 2023 10:12:05) |
  | xxx.xxx.xxx.xxx | zone2 | ACTIVE | 4.1.0.0_100000192023032010-0265dfc6d00ff4f0ff4ad2710504a18962abaef6(Mar 20 2023 10:12:05) |
  +-----------------+-------+--------+-------------------------------------------------------------------------------------------+
  

  obclient> show parameters like 'min_observer_version';
  

  The returned result is as follows:

  +-------+----------+-----------------+----------+----------------------+-----------+---------+--------------------------+--------------+---------+---------+-------------------+
  | zone  | svr_type | svr_ip          | svr_port | name                 | data_type | value   | info                     | section      | scope   | source  | edit_level        |
  +-------+----------+-----------------+----------+----------------------+-----------+---------+--------------------------+--------------+---------+---------+-------------------+
  | zone1 | observer | xxx.xxx.xxx.xxx |     2882 | min_observer_version | NULL      | 4.1.0.0 | the min observer version | ROOT_SERVICE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE |
  | zone3 | observer | xxx.xxx.xxx.xxx |     2882 | min_observer_version | NULL      | 4.1.0.0 | the min observer version | ROOT_SERVICE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE |
  | zone2 | observer | xxx.xxx.xxx.xxx |     2882 | min_observer_version | NULL      | 4.1.0.0 | the min observer version | ROOT_SERVICE | CLUSTER | DEFAULT | DYNAMIC_EFFECTIVE |
  +-------+----------+-----------------+----------+----------------------+-----------+---------+--------------------------+--------------+---------+---------+-------------------+