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

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

前提条件

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

手順

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

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

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

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

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

2. 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 ディレクトリに保存されます。

3. 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 の例から得られるアップグレードの順序は以下の通りです：

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

2. 現在OceanBaseクラスタV4.1.0.0またはV4.1.0.1を使用している場合、アップグレード時にOceanBaseクラスタは直接V4.2.0.0にアップグレードできます。

3. 現在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：クラスタ構成パラメータのバックアップ

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

• server_permanent_offline_time
• enable_rebalance
• enable_rereplication

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パッケージのアップロードとインストール

1. 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
   

2. 以下のコマンドを使用してOceanBase RPMパッケージをインストールします。

   注意

   • アップグレードパスにbarrierバージョンが存在する場合は、まず対応するbarrierバージョンのRPMパッケージをインストールしてください。クラスタが正常にbarrierバージョンにアップグレードされた後、ターゲットバージョンのRPMパッケージをインストールします。
   • アップグレードパスに複数のbarrierバージョンがある場合は、順番にbarrierバージョンをインストール・アップグレードし、クラスタが最後のbarrierバージョンに正常にアップグレードされた後、ターゲットバージョンのRPMパッケージをインストールします。

   rpm -Uvh $rpm_name
   

   ここで、$rpm_name はRPMパッケージ名を表します。

   説明

   アップグレード関連のスクリプトと oceanbase_upgrade_dep.yml ファイルは、/home/admin/oceanbase/etc ディレクトリに保存されています。/home/admin/oceanbase/etc ディレクトリはOceanBaseデータベースのデフォルトインストールディレクトリです。

3. すべての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：ユーザーのパスワードを表します。

例：

1. 以下のコマンドを使用して、/home/admin/oceanbase/etcディレクトリに移動します。

   cd /home/admin/oceanbase/etc
   

2. 以下のコマンドを使用して、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スクリプトは以下のコマンドとアクションを実行します：

1. alter system begin upgrade。
2. alter system begin rolling upgrade。
3. special pre action：パラメータの無効化および設定の調整。
4. 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 ******

例：

1. 以下のコマンドを使用して、/home/admin/oceanbase/etcディレクトリに移動します。

   cd /home/admin/oceanbase/etc
   

2. 以下のコマンドを使用して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：クラスタのアップグレード

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

1. 以下のコマンドを実行して、クラスタレベルのヘルスチェックを行います。

   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******
      

2. Zoneを停止します（STOP ZONE）。

   注意

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

   root ユーザーでクラスタの sys テナントにログインし、以下のコマンドを使用してZoneを停止します。ここで、$zone_name はZoneの名前です。コマンドは以下のとおりです：

   ALTER SYSTEM STOP ZONE '$zone_name';
   

   STOP ZONE コマンドは、すべてのリーダーレプリカ（Leader）が切り替わった後に成功を返します。

   例：

   obclient [(none)]> ALTER SYSTEM STOP ZONE 'zone1';
   

   以下のSQLコマンドを使用して、Zoneの状態を確認できます。

   obclient [(none)]> SELECT ZONE,STATUS FROM oceanbase.DBA_OB_ZONES;
   

   実行結果は次のとおりです：

   +-------+----------+
   | ZONE  | STATUS   |
   +-------+----------+
   | zone1 | INACTIVE |
   | zone2 | ACTIVE   |
   | zone3 | ACTIVE   |
   +-------+----------+
   3 rows in set
   

3. Zone内のマシンでプロセスを停止し、新バージョンのバイナリに置き換えて再起動します。

   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プロセスを再度起動する際には、起動パラメータを指定する必要はありません。以前に設定したパラメータは既にパラメータファイルに書き込まれているためです。

4. Zoneレベルのヘルスチェックを実行します。

   Zoneレベルのヘルスチェックは、基本的にクラスタレベルのヘルスチェックロジックを再利用しており、指定されたZoneのすべてのマシンの関連状態を検証します。コマンドは以下のとおりです：

   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：Zoneの名前を表します。

   例：

   1. 以下のコマンドを使用して、/home/admin/oceanbase/etc ディレクトリに移動します。

      cd /home/admin/oceanbase/etc
      

   2. 以下のコマンドを使用して、upgrade_health_checker.py スクリプトを実行し、Zoneレベルのヘルスチェックを行います。

      [root@xxx /home/admin/oceanbase/etc]# python upgrade_health_checker.py -h 127.0.0.1 -P 2881 -u root@sys -p****** -z 'zone1'
      

5. Zoneを起動します（start zone）。

   root ユーザーでクラスタの sys テナントにログインし、以下のコマンドを使用してZoneを起動します。ここで、$zone_name はZoneの名前です。コマンドは以下のとおりです：

   ALTER SYSTEM START ZONE '$zone_name';
   

   例：

   obclient [(none)]> ALTER SYSTEM START ZONE 'zone1';
   

6. すべての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

パラメータの説明：

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

upgrade_post.pyスクリプトは以下のアップグレード処理を実行します：

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

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

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

完全な 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 ******

例：

1. 以下のコマンドを使用して、/home/admin/oceanbase/etcディレクトリに移動します。

   cd /home/admin/oceanbase/etc
   

2. 以下のコマンドを使用して 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の設定を参照してください。

関連ドキュメント

• OceanBaseデータベースへの接続に関する詳細は、接続方法の概要を参照してください。
• Zoneの起動に関する詳細は、Zoneの起動を参照してください。
• 構成型の変更に関する詳細は、ALTER SYSTEM PARAMETERを参照してください。