OceanBaseクラスタのアップグレード|V4.4.2|OceanBaseデータベース|OceanBaseデータベースドキュメント|分散データベース

本記事では、アップグレードスクリプトを使用してOceanBaseクラスタをアップグレードする方法について説明します。

注意

OceanBaseデータベースは、V4.2.x系またはそれ以前のバージョンからV4.3.xバージョンへのアップグレードは現在サポートされていません。

前提条件

すべてのOBServerノードにPython 2の環境がインストールされており、Python 2に対応したmysql.connectorモジュールがインストールされていること。

注意

OceanBaseクラスタがアービトレーションサービスに関連付けられている場合、OceanBaseクラスタのバージョンをアップグレードする際は、まずアービトレーションサービスのバージョンをアップグレードし、その後でOceanBaseクラスタのバージョンをアップグレードする必要があります。アービトレーションサービスのバージョンアップグレードの詳細については、アービトレーションサービスのアップグレードを参照してください。
システムテナントを使用して、ビューoceanbase.DBA_OB_ARBITRATION_SERVICEを照会することで、このOceanBaseクラスタがアービトレーションサービスに関連付けられているかどうかを確認できます。その他のアップグレードに関する注意事項については、アップグレードの概要を参照してください。

手順

注意

以下の手順でアップグレードスクリプトを実行する際、指定された -u パラメータは、sys テナントに対して読み取り・書き込みおよび SUPER 権限を持つユーザーである必要があります。

oceanbase_upgrade_dep.yml ファイルを分析します。
アップグレードの流れを確認します。
クラスタ構成パラメータをバックアップします。
対象のRPMパッケージをアップロードし、インストールします。
スクリプト upgrade_checker.py を実行します。
スクリプト upgrade_pre.py を実行します。
クラスタをアップグレードします。
スクリプト upgrade_post.py を実行します。
クラスタ構成パラメータを復元します。

ステップ１：oceanbase_upgrade_dep.ymlファイルの分析

対象バージョンのOceanBase RPMパッケージを解凍すると、oceanbase_upgrade_dep.yml ファイルが取得できます。このファイルには、OceanBaseクラスタのバージョンアップグレードトポロジーが記録されています。手順は以下のとおりです：

対象バージョンのOceanBase RPMインストールパッケージを取得します。

OceanBase公式Webサイトの左上隅で、リソース > ダウンロードセンターをクリックし、対応するバージョンのRPMパッケージを取得します。対応するバージョンのインストールパッケージが見つからない場合は、テクニカルサポートに連絡して対象バージョンのRPMパッケージを取得してください。
OceanBase RPMパッケージを解凍します。

以下のコマンドを使用して、OceanBase RPMパッケージを現在のディレクトリに解凍できます：
```
[xxx@xxx $rpm_dir]# sudo rpm2cpio $rpm_name | cpio -div
```
ここで、$rpm_name はRPMパッケージ名を表します。

説明

RPMパッケージの解凍が完了すると、RPMパッケージが保存されたディレクトリに home と use の2つのディレクトリが生成されます。アップグレード関連スクリプトと oceanbase_upgrade_dep.yml ファイルは home/admin/oceanbase/etc ディレクトリに保存されます。
oceanbase_upgrade_dep.yml ファイルを分析します。

oceanbase_upgrade_dep.yml ファイル内の関連プロパティの意味：
- version：現在のOceanBaseデータベースのバージョン番号。以下、現在のバージョンと略称します。
- can_be_upgraded_to：現在のOceanBaseデータベースのバージョンからアップグレード可能な対象バージョン番号。以下、対象バージョンと略称します。
- deprecated：現在のバージョンがアップグレードの対象バージョンとして使用できるかどうか。true の場合、アップグレードの対象バージョンとして使用できません。例えば、例の 4.1.0.0-100000982023031415 バージョンは対象バージョンとして使用できません。
- require_from_binary：アップグレードシーケンスに現在のバージョンが含まれる場合、その前に現在のバージョンにアップグレードする必要があるかどうか、すなわち現在のバージョンがアップグレードシーケンス内のバリアバージョンであるかどうか。
  - value：値が true の場合、when_come_from プロパティと組み合わせて使用します。
  - when_come_from：リストです。when_come_from が定義されていない場合、任意のバージョンから対象バージョンへのアップグレードには、まず現在のバリアバージョンにアップグレードする必要があります。when_come_from が定義されている場合、リスト内のバージョン番号から対象バージョンへのアップグレードには、まず現在のバリアバージョンにアップグレードする必要があります。例えば、例の 4.0.0.0 および 4.1.0.0-100000982023031415 バージョンのOceanBaseクラスタをV4.2.0.0バージョンにアップグレードするには、まずV4.1.0.1（バリア）バージョンにアップグレードする必要があります。
例：

假定 oceanbase_upgrade_dep.yml ファイル内のOceanBaseクラスタ各バージョンのアップグレード依存関係は以下のとおりです：
```
- version: 4.0.0.0
  can_be_upgraded_to:
      - 4.1.0.0

- version: 4.1.0.0-100000982023031415
  can_be_upgraded_to:
    - 4.1.0.0
  deprecated: True

- version: 4.1.0.0
  can_be_upgraded_to:
      - 4.1.0.1

- version: 4.1.0.1
  can_be_upgraded_to:
      - 4.2.0.0
  require_from_binary:
    value: True
    when_come_from: [4.0.0.0, 4.1.0.0-100000982023031415]

# 4.3.0.x
- version: 4.3.0.0
  can_be_upgraded_to:
      - 4.3.0.1

- version: 4.3.0.1
  can_be_upgraded_to:
      - 4.3.1.0
```
この例ファイルを分析することで、以下のアップグレードシーケンスを得ることができます：
1. V4.0.0.0 > V4.1.0.0 > V4.1.0.1(バリア) > V4.2.0.0
2. V4.1.0.0-100000982023031415 > V4.1.0.0 > V4.1.0.1(バリア) > V4.2.0.0
3. V4.1.0.0 > V4.1.0.1 > V4.2.0.0
4. V4.3.0.0 > V4.3.0.1 > V4.3.1.0
注意

アップグレードシーケンスにバリアバージョンが存在する場合、アップグレードパス内のすべてのバリアバージョンのOceanBase RPMパッケージも取得する必要があります。

ステップ2：アップグレードプロセスの確認

注意

OceanBaseクラスタの現在のバージョンと目標バージョンの間にバリアバージョンが存在する場合、OceanBaseクラスタはまずそのバリアバージョンにアップグレードし、その後バリアバージョンから目標バージョンにアップグレードする必要があります。

ステップ1 の例によるアップグレードシーケンスから、以下の情報を得ることができます：

現在OceanBaseクラスタV4.0.0.0またはV4.1.0.0-100000982023031415を使用している場合、アップグレード時にOceanBaseクラスタはまずV4.1.0.1（バリア）バージョンにアップグレードし、その後V4.1.0.1（バリア）バージョンからV4.2.0.0バージョンにアップグレードする必要があります。
現在OceanBaseクラスタV4.1.0.0またはV4.1.0.1を使用している場合、アップグレード時にOceanBaseクラスタは直接V4.2.0.0バージョンにアップグレードできます。
現在OceanBaseクラスタV4.3.0.0またはV4.3.0.1を使用している場合、アップグレード時にOceanBaseクラスタは直接V4.3.1.0バージョンにアップグレードできます。

例：

以下では、3レプリカのOceanBaseクラスタを例にアップグレードプロセスを説明します。

アップグレードパスにバリアバージョンが含まれている場合。現在のOceanBaseクラスタバージョンがV4.0.0.0の場合、アップグレードプロセスは以下のとおりです：
1. まず、Zone1をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードし、次にZone2をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードし、さらにZone3をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードします。これにより、クラスタ全体がV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードされます。
2. その後、再びZoneの順序に従って、Zone1、Zone2、Zone3をV4.1.0.1（バリア）バージョンからV4.2.0.0にアップグレードします。すべてのZoneがV4.2.0.0にアップグレードされたら、クラスタのアップグレードは完了です。
アップグレードパスにバリアバージョンが含まれていない場合。現在のOceanBaseクラスタバージョンがV4.3.0.0の場合、アップグレードプロセスは以下のとおりです：

まず、Zone1をV4.3.0.0からV4.3.1.0にアップグレードし、次にZone2をV4.3.0.0からV4.3.1.0にアップグレードし、さらにZone3をV4.3.0.0からV4.3.1.0にアップグレードします。すべてのZoneがV4.3.1.0にアップグレードされたら、クラスタのアップグレードは完了です。

ステップ3：クラスタ構成パラメータのバックアップ

アップグレードプロセスを開始する前に、以下の構成パラメータの旧値をバックアップし、アップグレード後に復元するために使用します：

sys テナント（システムテナント）で以下のSQLステートメントを実行し、バックアップが必要な構成パラメータの値を取得します：

SELECT SVR_IP,ZONE,NAME,VALUE FROM OCEANBASE.GV$OB_PARAMETERS WHERE NAME IN ("server_permanent_offline_time", "enable_rebalance", "enable_rereplication");

ステップ4：ターゲットRPMパッケージのアップロードとインストール

scp コマンドを使用して、アップグレードに必要なOceanBase RPMパッケージをOBServerノードにアップロードします。
```
scp $rpm_name admin@$observer_ip:/$rpm_dir
```
パラメータの説明：
- $rpm_name：RPMパッケージの名前を表します。
- $observer_ip：OBServerノードのIPアドレスを表します。
- $rpm_dir：RPMパッケージを格納するディレクトリを表します。
例：
```
scp oceanbase-4.2.0.0-100010022023081911.el7.x86_64.rpm admin@10.10.10.1:/home/admin/rpm
```
以下のコマンドを使用して、OceanBase RPMパッケージをインストールします。
注意
- アップグレードパスにバリアバージョンが存在する場合は、まず対応するバリアバージョンのRPMパッケージをインストールしてください。クラスタがバリアバージョンに正常にアップグレードされた後、対象バージョンのRPMパッケージをインストールします。
- アップグレードパスに複数のバリアバージョンが存在する場合は、順番にバリアバージョンをインストール・アップグレードし、クラスタが最後のバリアバージョンに正常にアップグレードされた後、対象バージョンのRPMパッケージをインストールします。
```
rpm -Uvh $rpm_name
```
ここで、$rpm_name はRPMパッケージの名前を表します。

説明

アップグレード関連のスクリプトと oceanbase_upgrade_dep.yml ファイルは、/home/admin/oceanbase/etc ディレクトリに配置されています。ディレクトリ /home/admin/oceanbase/etc はOceanBaseデータベースのデフォルトインストールディレクトリです。
すべてのOBServerノードに対象バージョンのRPMパッケージがインストールされるまで、手順1～2を繰り返します。

ステップ5：スクリプト upgrade_checker.py を実行する

任意のOBServerノードで、sys テナントがそのOBServerノードに直接接続するためのログイン情報を指定し、upgrade_checker.py スクリプトを実行してアップグレードの事前チェックを行います。スクリプトの実行が成功すれば、アップグレードを続行できます。コマンドは以下のとおりです：

python upgrade_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

パラメータの説明：

$user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_checker.py スクリプトを実行し、アップグレードの事前チェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ6：スクリプト upgrade_pre.py を実行する

任意のOBServerノードで、sys テナントがそのOBServerノードに直接接続するためのログイン情報を指定し、upgrade_pre.py スクリプトを実行します。スクリプトの実行が成功すれば、アップグレードを続行できます。コマンドは以下のとおりです：

python upgrade_pre.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

パラメータの説明：

$user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

upgrade_pre.py スクリプトは以下のコマンドとアクションを実行します：

alter system begin upgrade。
alter system begin rolling upgrade。
special pre action：パラメータの無効化および調整。
health check: クラスタレベルのヘルスチェック。

完全な upgrade_pre.py スクリプトの機能は以下のとおりです：

./upgrade_pre.py [OPTIONS]

-I, --help          Display this help and exit.
-V, --version       Output version information and exit.
-h, --host=name     Connect to host.
-P, --port=name     Port number to use for connection.
-u, --user=name     User for login.
-p, --password=name Password to use when connecting to server. If password is
                    not given it's empty string "".
-t, --timeout=name  Cmd/Query execute timeout(s).
-m, --module=name   Modules to run. Modules should be a string combined by some of
                    the following strings:
                    1. begin_upgrade
                    2. begin_rolling_upgrade
                    3. special_action
                    4. health_check
                    5. all: "all" represents that all modules should be run.
                    They are splitted by ",".
                    For example: -m all, or --module=begin_upgrade,begin_rolling_upgrade,special_action
-l, --log-file=name Log file path. If log file path is not given it's ./upgrade_pre.log


Maybe you want to run cmd like that:
./upgrade_pre.py -h 127.0.0.1 -P 2881 -u ******  -p ******

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_pre.py スクリプトを実行し、アップグレード前チェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_pre.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ7：クラスタのアップグレード

ゾーンごとにアップグレードします。各ゾーンについて、以下の手順を1回ずつ実行します。zone1 を例に説明します。

以下のコマンドを実行して、クラスタレベルのヘルスチェックを行います。
```
python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password
```
パラメータの説明：
- $user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
- $password：ユーザーのパスワードを表します。
例：
1. 以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
2. 以下のコマンドを使用して、upgrade_health_checker.py スクリプトを実行し、クラスタレベルのヘルスチェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```
ゾーンを停止します（STOP ZONE）。

注意

単一マシンまたは単一レプリカのOceanBaseデータベースをアップグレードする場合は、ゾーンを停止する必要はありません（STOP ZONE）。

root ユーザーでクラスタの sys テナントにログインし、以下のコマンドを使用してゾーンを停止します。ここで、$zone_name はゾーン名です。コマンドは以下のとおりです：
```
ALTER SYSTEM STOP ZONE '$zone_name';
```
STOP ZONE コマンドは、リーダーレプリカ（Leader）がすべて切り替わった後に正常終了します。

例：
```
obclient [(none)]> ALTER SYSTEM STOP ZONE 'zone1';
```
以下のSQLコマンドを使用してゾーンの状態を確認できます。
```
obclient [(none)]> SELECT ZONE,STATUS FROM oceanbase.DBA_OB_ZONES;
```
実行結果は次のとおりです：
```
+-------+----------+
| ZONE  | STATUS   |
+-------+----------+
| zone1 | INACTIVE |
| zone2 | ACTIVE   |
| zone3 | ACTIVE   |
+-------+----------+
3 rows in set
```
ゾーン内のマシンでプロセスを停止し、新バージョンのバイナリに置き換えて再起動します。

observerプロセスを停止してから、再起動します。
1. adminユーザーに切り替えます。
```
[root@xxx /home/admin/oceanbase/etc]# su - admin
```
2. observerプロセスを停止します。
```
-bash-4.2$ kill -9 `pidof observer`
```
3. observerプロセスを再起動します。
```
-bash-4.2$ cd /home/admin/oceanbase && /home/admin/oceanbase/bin/observer
```
  説明
  
  observerプロセスを再度起動する際は、起動パラメータを指定する必要はありません。以前の起動パラメータはすでにパラメータファイルに書き込まれているためです。
ゾーンレベルのヘルスチェックを実行します。

ゾーンレベルのヘルスチェックは、基本的にクラスタレベルのヘルスチェックロジックを再利用しており、指定されたゾーン内のすべてのマシンの関連状態を検証します。コマンドは以下のとおりです：
```
python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password -z '$zone_name'
```
パラメータの説明：
- $user_name：sysテナントがグローバルなシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
- $password：ユーザーのパスワードを表します。
- $zone_name：ゾーンの名前を表します。
例：
1. 以下のコマンドを使用して、/home/admin/oceanbase/etcディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
2. 以下のコマンドを使用してupgrade_health_checker.pyスクリプトを実行し、ゾーンレベルのヘルスチェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p****** -z 'zone1'
```
ゾーンを起動します(start zone)。

rootユーザーでクラスタのsysテナントにログインし、以下のコマンドを使用してゾーンを起動します。ここで、$zone_nameはゾーンの名前です。コマンドは以下のとおりです：
```
ALTER SYSTEM START ZONE '$zone_name';
```
例：
```
obclient [(none)]> ALTER SYSTEM START ZONE 'zone1';
```
すべてのZoneのアップグレードが完了するまで、手順1～5を繰り返します。

ステップ8：スクリプトupgrade_post.pyを実行する

任意のOBServerノードで、sysテナントのログイン情報を使用してOBServerノードに直接接続し、upgrade_post.pyスクリプトを実行して、主要なアップグレード操作と関連チェックを完了します。コマンドは以下のとおりです：

python upgrade_post.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

注意

アップグレードスクリプト upgrade_post.py の実行時にエラーが発生した場合、その原因はRS切り替えが行われた可能性が高いです。以下の手順でトラブルシューティングと修正を行うことを推奨します：

SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE job_type = 'upgrade_all' ORDER BY job_id DESC LIMIT 1; を実行して、アップグレードタスクの状態を確認できます。JOB_STATUS が inprogress に表示され、かつ MODIFY_TIME が最新時間（現在時刻からの時間差が短い）であれば、ALTER SYSTEM RUN UPGRADE JOB 'UPGRADE_ALL'; コマンドを手動で実行してこの問題を解決できます。
アップグレードスクリプトを再実行します。

パラメータの説明：

$user_name：sysテナントがグローバルシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

upgrade_post.pyスクリプトは以下のアップグレード操作を完了します：

クラスタレベルのヘルスチェック。
alter system end rolling upgrade。
テナントごとにbegin upgradeを実行します。
テナントごとにシステム変数の修正を実行します。
テナントごとにシステムテーブルの修正を実行します。
テナントごとに仮想テーブル/ビューの修正を実行します。
テナントごとにバージョン関連のアップグレード操作を実行します。
テナントごとに内部テーブルの自己検査操作を実行します。
テナントごとにend upgradeを実行します。
alter system end upgrade：クラスタのアップグレード状態を終了します。
upgrade post check：アップグレード中に無効になった一部のパラメータを再び有効にし、チェックを実行します。

上記のステップ3～5、7、9は、以下のアップグレードシナリオでは実行されません：

同一バージョンへのアップグレード。
バージョン間アップグレードで、元のバージョンとターゲットバージョンのデータバージョンが一致する場合。

完全な upgrade_post.py スクリプトの機能は以下のとおりです：

./upgrade_post.py [OPTIONS]

-I, --help          Display this help and exit.
-V, --version       Output version information and exit.
-h, --host=name     Connect to host.
-P, --port=name     Port number to use for connection.
-u, --user=name     User for login.
-p, --password=name Password to use when connecting to server. If password is
                    not given it's empty string "".
-t, --timeout=name  Cmd/Query execute timeout(s).
-m, --module=name   Modules to run. Modules should be a string combined by some of
                    the following strings:
                    1. health_check
                    2. end_rolling_upgrade
                    3. tenant_upgrade
                    4. end_upgrade
                    5. post_check
                    6. all: "all" represents that all modules should be run.
                    They are splitted by ",".
                    For example: -m all, or --module=health_check,begin_rolling_upgrade
-l, --log-file=name Log file path. If log file path is not given it's ./upgrade_pre.log


Maybe you want to run cmd like that:
./upgrade_post.py -h 127.0.0.1 -P 2881 -u *** -p ******

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_post.py スクリプトを実行し、主要なアップグレード操作と関連チェックを完了します。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_post.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ9：クラスタ構成パラメータの復元

ステップ3 でバックアップした構成パラメータの旧値に基づき、root ユーザーでクラスタの sys テナントにログインし、以下のコマンドを使用して関連する構成パラメータを復元します。

ALTER SYSTEM SET $parameter value= $parameter_value

パラメータの説明：

$parameter：構成パラメータ名を表します。
$parameter_value：構成パラメータの値を表します。

例：

server_permanent_offline_time の値を復元します。

obclient [(none)]> ALTER SYSTEM SET server_permanent_offline_time = '3600s';

enable_rebalance の値を復元します。

obclient [(none)]> ALTER SYSTEM SET enable_rebalance = 'True';

enable_rereplication の値を復元します。

obclient [(none)]> ALTER SYSTEM SET enable_rereplication = 'True';

次のステップ

アップグレード後の確認

アップグレードが完了したかどうかを確認するには、アップグレード後の確認を参照してください。

cgroupの再設定

アップグレード前にOceanBaseクラスタでcgroupが設定されていた場合は、OceanBaseクラスタのアップグレード後にcgroupを再設定する必要があります。詳細については、cgroupの設定を参照してください。

前提条件

すべてのOBServerノードにPython 2の環境がインストールされており、Python 2に対応したmysql.connectorモジュールがインストールされていること。

注意

手順

注意

oceanbase_upgrade_dep.yml ファイルを分析します。
アップグレードの流れを確認します。
クラスタ構成パラメータをバックアップします。
対象のRPMパッケージをアップロードし、インストールします。
スクリプト upgrade_checker.py を実行します。
スクリプト upgrade_pre.py を実行します。
クラスタをアップグレードします。
スクリプト upgrade_post.py を実行します。
クラスタ構成パラメータを復元します。

ステップ１：oceanbase_upgrade_dep.ymlファイルの分析

対象バージョンのOceanBase RPMインストールパッケージを取得します。

OceanBase公式Webサイトの左上隅で、リソース > ダウンロードセンターをクリックし、対応するバージョンのRPMパッケージを取得します。対応するバージョンのインストールパッケージが見つからない場合は、テクニカルサポートに連絡して対象バージョンのRPMパッケージを取得してください。
OceanBase RPMパッケージを解凍します。

以下のコマンドを使用して、OceanBase RPMパッケージを現在のディレクトリに解凍できます：
```
[xxx@xxx $rpm_dir]# sudo rpm2cpio $rpm_name | cpio -div
```
ここで、$rpm_name はRPMパッケージ名を表します。

説明

RPMパッケージの解凍が完了すると、RPMパッケージが保存されたディレクトリに home と use の2つのディレクトリが生成されます。アップグレード関連スクリプトと oceanbase_upgrade_dep.yml ファイルは home/admin/oceanbase/etc ディレクトリに保存されます。
oceanbase_upgrade_dep.yml ファイルを分析します。

oceanbase_upgrade_dep.yml ファイル内の関連プロパティの意味：
- version：現在のOceanBaseデータベースのバージョン番号。以下、現在のバージョンと略称します。
- can_be_upgraded_to：現在のOceanBaseデータベースのバージョンからアップグレード可能な対象バージョン番号。以下、対象バージョンと略称します。
- deprecated：現在のバージョンがアップグレードの対象バージョンとして使用できるかどうか。true の場合、アップグレードの対象バージョンとして使用できません。例えば、例の 4.1.0.0-100000982023031415 バージョンは対象バージョンとして使用できません。
- require_from_binary：アップグレードシーケンスに現在のバージョンが含まれる場合、その前に現在のバージョンにアップグレードする必要があるかどうか、すなわち現在のバージョンがアップグレードシーケンス内のバリアバージョンであるかどうか。
  - value：値が true の場合、when_come_from プロパティと組み合わせて使用します。
  - when_come_from：リストです。when_come_from が定義されていない場合、任意のバージョンから対象バージョンへのアップグレードには、まず現在のバリアバージョンにアップグレードする必要があります。when_come_from が定義されている場合、リスト内のバージョン番号から対象バージョンへのアップグレードには、まず現在のバリアバージョンにアップグレードする必要があります。例えば、例の 4.0.0.0 および 4.1.0.0-100000982023031415 バージョンのOceanBaseクラスタをV4.2.0.0バージョンにアップグレードするには、まずV4.1.0.1（バリア）バージョンにアップグレードする必要があります。
例：

假定 oceanbase_upgrade_dep.yml ファイル内のOceanBaseクラスタ各バージョンのアップグレード依存関係は以下のとおりです：
```
- version: 4.0.0.0
  can_be_upgraded_to:
      - 4.1.0.0

- version: 4.1.0.0-100000982023031415
  can_be_upgraded_to:
    - 4.1.0.0
  deprecated: True

- version: 4.1.0.0
  can_be_upgraded_to:
      - 4.1.0.1

- version: 4.1.0.1
  can_be_upgraded_to:
      - 4.2.0.0
  require_from_binary:
    value: True
    when_come_from: [4.0.0.0, 4.1.0.0-100000982023031415]

# 4.3.0.x
- version: 4.3.0.0
  can_be_upgraded_to:
      - 4.3.0.1

- version: 4.3.0.1
  can_be_upgraded_to:
      - 4.3.1.0
```
この例ファイルを分析することで、以下のアップグレードシーケンスを得ることができます：
1. V4.0.0.0 > V4.1.0.0 > V4.1.0.1(バリア) > V4.2.0.0
2. V4.1.0.0-100000982023031415 > V4.1.0.0 > V4.1.0.1(バリア) > V4.2.0.0
3. V4.1.0.0 > V4.1.0.1 > V4.2.0.0
4. V4.3.0.0 > V4.3.0.1 > V4.3.1.0
注意

アップグレードシーケンスにバリアバージョンが存在する場合、アップグレードパス内のすべてのバリアバージョンのOceanBase RPMパッケージも取得する必要があります。

ステップ2：アップグレードプロセスの確認

注意

ステップ1 の例によるアップグレードシーケンスから、以下の情報を得ることができます：

現在OceanBaseクラスタV4.0.0.0またはV4.1.0.0-100000982023031415を使用している場合、アップグレード時にOceanBaseクラスタはまずV4.1.0.1（バリア）バージョンにアップグレードし、その後V4.1.0.1（バリア）バージョンからV4.2.0.0バージョンにアップグレードする必要があります。
現在OceanBaseクラスタV4.1.0.0またはV4.1.0.1を使用している場合、アップグレード時にOceanBaseクラスタは直接V4.2.0.0バージョンにアップグレードできます。
現在OceanBaseクラスタV4.3.0.0またはV4.3.0.1を使用している場合、アップグレード時にOceanBaseクラスタは直接V4.3.1.0バージョンにアップグレードできます。

例：

以下では、3レプリカのOceanBaseクラスタを例にアップグレードプロセスを説明します。

アップグレードパスにバリアバージョンが含まれている場合。現在のOceanBaseクラスタバージョンがV4.0.0.0の場合、アップグレードプロセスは以下のとおりです：
1. まず、Zone1をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードし、次にZone2をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードし、さらにZone3をV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードします。これにより、クラスタ全体がV4.0.0.0からV4.1.0.1（バリア）バージョンにアップグレードされます。
2. その後、再びZoneの順序に従って、Zone1、Zone2、Zone3をV4.1.0.1（バリア）バージョンからV4.2.0.0にアップグレードします。すべてのZoneがV4.2.0.0にアップグレードされたら、クラスタのアップグレードは完了です。
アップグレードパスにバリアバージョンが含まれていない場合。現在のOceanBaseクラスタバージョンがV4.3.0.0の場合、アップグレードプロセスは以下のとおりです：

まず、Zone1をV4.3.0.0からV4.3.1.0にアップグレードし、次にZone2をV4.3.0.0からV4.3.1.0にアップグレードし、さらにZone3をV4.3.0.0からV4.3.1.0にアップグレードします。すべてのZoneがV4.3.1.0にアップグレードされたら、クラスタのアップグレードは完了です。

ステップ3：クラスタ構成パラメータのバックアップ

アップグレードプロセスを開始する前に、以下の構成パラメータの旧値をバックアップし、アップグレード後に復元するために使用します：

sys テナント（システムテナント）で以下のSQLステートメントを実行し、バックアップが必要な構成パラメータの値を取得します：

SELECT SVR_IP,ZONE,NAME,VALUE FROM OCEANBASE.GV$OB_PARAMETERS WHERE NAME IN ("server_permanent_offline_time", "enable_rebalance", "enable_rereplication");

ステップ4：ターゲットRPMパッケージのアップロードとインストール

scp コマンドを使用して、アップグレードに必要なOceanBase RPMパッケージをOBServerノードにアップロードします。
```
scp $rpm_name admin@$observer_ip:/$rpm_dir
```
パラメータの説明：
- $rpm_name：RPMパッケージの名前を表します。
- $observer_ip：OBServerノードのIPアドレスを表します。
- $rpm_dir：RPMパッケージを格納するディレクトリを表します。
例：
```
scp oceanbase-4.2.0.0-100010022023081911.el7.x86_64.rpm admin@10.10.10.1:/home/admin/rpm
```
以下のコマンドを使用して、OceanBase RPMパッケージをインストールします。
注意
- アップグレードパスにバリアバージョンが存在する場合は、まず対応するバリアバージョンのRPMパッケージをインストールしてください。クラスタがバリアバージョンに正常にアップグレードされた後、対象バージョンのRPMパッケージをインストールします。
- アップグレードパスに複数のバリアバージョンが存在する場合は、順番にバリアバージョンをインストール・アップグレードし、クラスタが最後のバリアバージョンに正常にアップグレードされた後、対象バージョンのRPMパッケージをインストールします。
```
rpm -Uvh $rpm_name
```
ここで、$rpm_name はRPMパッケージの名前を表します。

説明

アップグレード関連のスクリプトと oceanbase_upgrade_dep.yml ファイルは、/home/admin/oceanbase/etc ディレクトリに配置されています。ディレクトリ /home/admin/oceanbase/etc はOceanBaseデータベースのデフォルトインストールディレクトリです。
すべてのOBServerノードに対象バージョンのRPMパッケージがインストールされるまで、手順1～2を繰り返します。

ステップ5：スクリプト upgrade_checker.py を実行する

python upgrade_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

パラメータの説明：

$user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_checker.py スクリプトを実行し、アップグレードの事前チェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ6：スクリプト upgrade_pre.py を実行する

python upgrade_pre.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

パラメータの説明：

$user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

upgrade_pre.py スクリプトは以下のコマンドとアクションを実行します：

alter system begin upgrade。
alter system begin rolling upgrade。
special pre action：パラメータの無効化および調整。
health check: クラスタレベルのヘルスチェック。

完全な upgrade_pre.py スクリプトの機能は以下のとおりです：

./upgrade_pre.py [OPTIONS]

-I, --help          Display this help and exit.
-V, --version       Output version information and exit.
-h, --host=name     Connect to host.
-P, --port=name     Port number to use for connection.
-u, --user=name     User for login.
-p, --password=name Password to use when connecting to server. If password is
                    not given it's empty string "".
-t, --timeout=name  Cmd/Query execute timeout(s).
-m, --module=name   Modules to run. Modules should be a string combined by some of
                    the following strings:
                    1. begin_upgrade
                    2. begin_rolling_upgrade
                    3. special_action
                    4. health_check
                    5. all: "all" represents that all modules should be run.
                    They are splitted by ",".
                    For example: -m all, or --module=begin_upgrade,begin_rolling_upgrade,special_action
-l, --log-file=name Log file path. If log file path is not given it's ./upgrade_pre.log


Maybe you want to run cmd like that:
./upgrade_pre.py -h 127.0.0.1 -P 2881 -u ******  -p ******

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_pre.py スクリプトを実行し、アップグレード前チェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_pre.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ7：クラスタのアップグレード

ゾーンごとにアップグレードします。各ゾーンについて、以下の手順を1回ずつ実行します。zone1 を例に説明します。

以下のコマンドを実行して、クラスタレベルのヘルスチェックを行います。
```
python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password
```
パラメータの説明：
- $user_name：sys テナントがグローバルシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
- $password：ユーザーのパスワードを表します。
例：
1. 以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
2. 以下のコマンドを使用して、upgrade_health_checker.py スクリプトを実行し、クラスタレベルのヘルスチェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```
ゾーンを停止します（STOP ZONE）。

注意

単一マシンまたは単一レプリカのOceanBaseデータベースをアップグレードする場合は、ゾーンを停止する必要はありません（STOP ZONE）。

root ユーザーでクラスタの sys テナントにログインし、以下のコマンドを使用してゾーンを停止します。ここで、$zone_name はゾーン名です。コマンドは以下のとおりです：
```
ALTER SYSTEM STOP ZONE '$zone_name';
```
STOP ZONE コマンドは、リーダーレプリカ（Leader）がすべて切り替わった後に正常終了します。

例：
```
obclient [(none)]> ALTER SYSTEM STOP ZONE 'zone1';
```
以下のSQLコマンドを使用してゾーンの状態を確認できます。
```
obclient [(none)]> SELECT ZONE,STATUS FROM oceanbase.DBA_OB_ZONES;
```
実行結果は次のとおりです：
```
+-------+----------+
| ZONE  | STATUS   |
+-------+----------+
| zone1 | INACTIVE |
| zone2 | ACTIVE   |
| zone3 | ACTIVE   |
+-------+----------+
3 rows in set
```
ゾーン内のマシンでプロセスを停止し、新バージョンのバイナリに置き換えて再起動します。

observerプロセスを停止してから、再起動します。
1. adminユーザーに切り替えます。
```
[root@xxx /home/admin/oceanbase/etc]# su - admin
```
2. observerプロセスを停止します。
```
-bash-4.2$ kill -9 `pidof observer`
```
3. observerプロセスを再起動します。
```
-bash-4.2$ cd /home/admin/oceanbase && /home/admin/oceanbase/bin/observer
```
  説明
  
  observerプロセスを再度起動する際は、起動パラメータを指定する必要はありません。以前の起動パラメータはすでにパラメータファイルに書き込まれているためです。
ゾーンレベルのヘルスチェックを実行します。

ゾーンレベルのヘルスチェックは、基本的にクラスタレベルのヘルスチェックロジックを再利用しており、指定されたゾーン内のすべてのマシンの関連状態を検証します。コマンドは以下のとおりです：
```
python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password -z '$zone_name'
```
パラメータの説明：
- $user_name：sysテナントがグローバルなシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
- $password：ユーザーのパスワードを表します。
- $zone_name：ゾーンの名前を表します。
例：
1. 以下のコマンドを使用して、/home/admin/oceanbase/etcディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
2. 以下のコマンドを使用してupgrade_health_checker.pyスクリプトを実行し、ゾーンレベルのヘルスチェックを行います。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p****** -z 'zone1'
```
ゾーンを起動します(start zone)。

rootユーザーでクラスタのsysテナントにログインし、以下のコマンドを使用してゾーンを起動します。ここで、$zone_nameはゾーンの名前です。コマンドは以下のとおりです：
```
ALTER SYSTEM START ZONE '$zone_name';
```
例：
```
obclient [(none)]> ALTER SYSTEM START ZONE 'zone1';
```
すべてのZoneのアップグレードが完了するまで、手順1～5を繰り返します。

ステップ8：スクリプトupgrade_post.pyを実行する

python upgrade_post.py -h 127.0.0.1 -P 2881 -u $user_name@sys -p$password

注意

SELECT * FROM oceanbase.DBA_OB_TENANT_JOBS WHERE job_type = 'upgrade_all' ORDER BY job_id DESC LIMIT 1; を実行して、アップグレードタスクの状態を確認できます。JOB_STATUS が inprogress に表示され、かつ MODIFY_TIME が最新時間（現在時刻からの時間差が短い）であれば、ALTER SYSTEM RUN UPGRADE JOB 'UPGRADE_ALL'; コマンドを手動で実行してこの問題を解決できます。
アップグレードスクリプトを再実行します。

パラメータの説明：

$user_name：sysテナントがグローバルシステムパラメータの読み取り、書き込み、変更を行う権限を持つユーザーを表します。
$password：ユーザーのパスワードを表します。

upgrade_post.pyスクリプトは以下のアップグレード操作を完了します：

クラスタレベルのヘルスチェック。
alter system end rolling upgrade。
テナントごとにbegin upgradeを実行します。
テナントごとにシステム変数の修正を実行します。
テナントごとにシステムテーブルの修正を実行します。
テナントごとに仮想テーブル/ビューの修正を実行します。
テナントごとにバージョン関連のアップグレード操作を実行します。
テナントごとに内部テーブルの自己検査操作を実行します。
テナントごとにend upgradeを実行します。
alter system end upgrade：クラスタのアップグレード状態を終了します。
upgrade post check：アップグレード中に無効になった一部のパラメータを再び有効にし、チェックを実行します。

上記のステップ3～5、7、9は、以下のアップグレードシナリオでは実行されません：

同一バージョンへのアップグレード。
バージョン間アップグレードで、元のバージョンとターゲットバージョンのデータバージョンが一致する場合。

完全な upgrade_post.py スクリプトの機能は以下のとおりです：

./upgrade_post.py [OPTIONS]

-I, --help          Display this help and exit.
-V, --version       Output version information and exit.
-h, --host=name     Connect to host.
-P, --port=name     Port number to use for connection.
-u, --user=name     User for login.
-p, --password=name Password to use when connecting to server. If password is
                    not given it's empty string "".
-t, --timeout=name  Cmd/Query execute timeout(s).
-m, --module=name   Modules to run. Modules should be a string combined by some of
                    the following strings:
                    1. health_check
                    2. end_rolling_upgrade
                    3. tenant_upgrade
                    4. end_upgrade
                    5. post_check
                    6. all: "all" represents that all modules should be run.
                    They are splitted by ",".
                    For example: -m all, or --module=health_check,begin_rolling_upgrade
-l, --log-file=name Log file path. If log file path is not given it's ./upgrade_pre.log


Maybe you want to run cmd like that:
./upgrade_post.py -h 127.0.0.1 -P 2881 -u *** -p ******

例：

以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。
```
cd /home/admin/oceanbase/etc
```
以下のコマンドを使用して upgrade_post.py スクリプトを実行し、主要なアップグレード操作と関連チェックを完了します。
```
[root@xxx /home/admin/oceanbase/etc]# python upgrade_post.py -h 127.0.0.1 -P 2881 -u root@sys -p******
```

ステップ9：クラスタ構成パラメータの復元

ALTER SYSTEM SET $parameter value= $parameter_value

パラメータの説明：

$parameter：構成パラメータ名を表します。
$parameter_value：構成パラメータの値を表します。

例：

server_permanent_offline_time の値を復元します。

obclient [(none)]> ALTER SYSTEM SET server_permanent_offline_time = '3600s';

enable_rebalance の値を復元します。

obclient [(none)]> ALTER SYSTEM SET enable_rebalance = 'True';

enable_rereplication の値を復元します。

obclient [(none)]> ALTER SYSTEM SET enable_rereplication = 'True';

次のステップ

アップグレード後の確認

アップグレードが完了したかどうかを確認するには、アップグレード後の確認を参照してください。

OceanBase

顧客事例

OceanBaseクラスタのアップグレード

注意

前提条件

注意

手順

注意

ステップ１：oceanbase_upgrade_dep.ymlファイルの分析

説明

注意

ステップ2：アップグレードプロセスの確認

注意

ステップ3：クラスタ構成パラメータのバックアップ

ステップ4：ターゲットRPMパッケージのアップロードとインストール

注意

説明

ステップ5：スクリプト upgrade_checker.py を実行する

ステップ6：スクリプト upgrade_pre.py を実行する

ステップ7：クラスタのアップグレード

注意

説明

ステップ8：スクリプトupgrade_post.pyを実行する

注意

ステップ9：クラスタ構成パラメータの復元

次のステップ

アップグレード後の確認

cgroupの再設定

関連ドキュメント

OceanBaseクラスタのアップグレード

注意

前提条件

注意

手順

注意

ステップ１：oceanbase_upgrade_dep.ymlファイルの分析

説明

注意

ステップ2：アップグレードプロセスの確認

注意

ステップ3：クラスタ構成パラメータのバックアップ

ステップ4：ターゲットRPMパッケージのアップロードとインストール

注意

説明

ステップ5：スクリプト upgrade_checker.py を実行する

ステップ6：スクリプト upgrade_pre.py を実行する

ステップ7：クラスタのアップグレード

注意

説明

ステップ8：スクリプトupgrade_post.pyを実行する

注意

ステップ9：クラスタ構成パラメータの復元

次のステップ

アップグレード後の確認

cgroupの再設定

関連ドキュメント