メインコンテンツまでスキップ
バージョン: 3.x

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

Dorisはローリングアップグレード機能を提供しており、FEおよびBEノードの段階的なアップグレードを可能にし、ダウンタイムを最小限に抑え、アップグレードプロセス中にシステムが動作し続けることを保証します。

バージョン互換性​

Dorisのバージョニングは3つのコンポーネントで構成されています：最初の桁はメジャーマイルストーンバージョンを表し、2番目の桁は機能バージョンを示し、3番目の桁はバグ修正に対応します。バグ修正バージョンでは新機能は導入されません。例えば、Dorisバージョン2.1.3では、「2」は2番目のマイルストーンバージョンを示し、「1」はこのマイルストーン下での機能バージョンを表し、「3」はこの機能バージョンの3番目のバグ修正を示します。

バージョンアップグレード時には、以下のルールが適用されます：

  • 3桁バージョン： 最初の2桁が同じバージョンは、3桁バージョン間で直接アップグレードできます。例えば、バージョン2.1.3はバージョン2.1.7に直接アップグレードできます。

  • 2桁および1桁バージョン： 2桁バージョンのクロスバージョンアップグレードは互換性の懸念により推奨されません。各2桁バージョンを順次アップグレードすることが推奨されます。例えば、バージョン3.0から3.3へのアップグレードは、3.0 -> 3.1 -> 3.2 -> 3.3の順序に従う必要があります。

詳細なバージョン情報はversioning rulesで確認できます。

アップグレードの注意事項​

アップグレードを実行する際は、以下に注意してください：

  • バージョン間の動作変更： アップグレード前にRelease Notesを確認して互換性の問題を特定してください。

  • クラスター内のタスクに再試行メカニズムを追加： アップグレード中はノードが順次再起動されます。クエリタスクやStream Loadインポートジョブのタスク失敗を避けるため、再試行メカニズムが設定されていることを確認してください。flink-doris-connectorやspark-doris-connectorを使用するRoutine Loadジョブには、すでにコードに再試行メカニズムが含まれており、追加のロジックは必要ありません。

  • レプリカ修復およびバランス機能を無効化： アップグレードプロセス中はこれらの機能を無効にしてください。アップグレード結果に関わらず、アップグレード完了後にこれらの機能を再有効化してください。

メタデータ互換性テスト​

Note

本番環境では、高可用性のために少なくとも3つのFEノードを設定することが推奨されます。FEノードが1つしかない場合は、アップグレード前にメタデータ互換性テストを実行する必要があります。メタデータ互換性は重要であり、非互換性によってアップグレード失敗やデータ損失が発生する可能性があります。各アップグレード前にメタデータ互換性テストを実施することが推奨されます。以下の点を念頭に置いてください：

  • 可能な限りFEノードの使用を避け、開発マシンまたはBEノードでメタデータ互換性テストを実行してください。

  • FEノードでテストを実施する必要がある場合は、非MasterノードでMaster以外のノードを使用し、元のFEプロセスを停止してください。

アップグレード前に、メタデータ非互換性による失敗を防ぐためにメタデータ互換性テストを実施してください。

  1. メタデータ情報のバックアップ：

    アップグレード開始前に、Master FEノードのメタデータをバックアップしてください。

    show frontendsコマンドを使用し、IsMaster列を参照してMaster FEノードを特定してください。FEメタデータは、FEノードを停止せずにホットバックアップできます。デフォルトでは、FEメタデータはfe/doris-metaディレクトリに保存されます。これはfe.conf設定ファイルのmeta_dirパラメータで確認できます。

  2. テストFEノードのfe.conf設定ファイルを変更：

    vi ${DORIS_NEW_HOME}/conf/fe.conf

以下のポート情報を変更し、すべてのポートが本番環境のものと異なることを確認して、clusterIDパラメータを更新してください：

...
## modify port
http_port = 18030
rpc_port = 19020
query_port = 19030
arrow_flight_sql_port = 19040
edit_log_port = 19010

## modify clusterIP
clusterId=<a_new_clusterIP, such as 123456>
...

  1. バックアップされたMaster FEメタデータを新しい互換性テスト環境にコピーします。

    cp ${DORIS_OLD_HOME}/fe/doris-meta/* ${DORIS_NEW_HOME}/fe/doris-meta

  2. コピーしたメタデータディレクトリ内のVERSIONファイルを編集して、cluster_idを新しいクラスターIPに更新します。例えば、以下の例に示すように123456に変更します：

    vi ${DORIS_NEW_HOME}/fe/doris-meta/image/VERSION
    clusterId=123456

  3. テスト環境でFEプロセスを開始します。

    sh ${DORIS_NEW_HOME}/bin/start_fe.sh --daemon --metadata_failure_recovery

2.0.2より前のバージョンでは、FEプロセスを開始する前にfe.confファイルにmetadata_failure_recoveryパラメータを追加してください：

echo "metadata_failure_recovery=true" >> ${DORIS_NEW_HOME}/conf/fe.conf
sh ${DORIS_NEW_HOME}/bin/start_fe.sh --daemon

  1. 上記で述べたクエリポート19030を使用するなど、MySQLコマンドを使用して現在のFEに接続することで、FEプロセスが正常に開始されたことを確認します。

    mysql -uroot -P19030 -h127.0.0.1

アップグレード手順​

アップグレードの詳細なプロセスは以下の通りです：

  1. レプリカ修復とバランス機能を無効にする

  2. BEノードをアップグレードする

  3. FEノードをアップグレードする

  4. レプリカ修復とバランス機能を有効にする

アップグレードプロセス中は、BEノードを最初にアップグレードし、その後FEノードをアップグレードするという原則に従う必要があります。FEをアップグレードする際は、Observer FEとFollower FEノードを最初にアップグレードし、その後Master FEノードをアップグレードします。

注意

通常、FEディレクトリ下の /bin および /lib ディレクトリと、BEディレクトリ下の /bin および /lib ディレクトリのみをアップグレードする必要があります。

バージョン2.0.2以降では、FEおよびBEデプロイメントパス下に custom_lib/ ディレクトリが追加されました（存在しない場合は手動で作成できます）。custom_lib/ ディレクトリは、hadoop-lzo-*.jar、orai18n.jar などのユーザー定義のサードパーティjarファイルを格納するために使用されます。このディレクトリはアップグレード中に置き換える必要はありません。

ステップ1：レプリカ修復とバランス機能を無効にする​

アップグレードプロセス中、ノードが再起動され、不要なクラスターバランシングとレプリカ修復ロジックがトリガーされる可能性があります。まず以下のコマンドを使用してこれらの機能を無効にします：

admin set frontend config("disable_balance" = "true");
admin set frontend config("disable_colocate_balance" = "true");
admin set frontend config("disable_tablet_scheduler" = "true");

Step 2: BEノードのアップグレード​

Note:

データの安全性を確保するため、アップグレードのミスや失敗によるデータ損失を避けるために、3つのレプリカを使用してデータを保存してください。

  1. マルチレプリカクラスターでは、1つのBEノードでプロセスを停止し、段階的なアップグレードを実行することを選択できます：

    sh ${DORIS_OLD_HOME}/be/bin/stop_be.sh

  2. BEディレクトリ内の/binおよび/libディレクトリの名前を変更します：

    mv ${DORIS_OLD_HOME}/be/bin ${DORIS_OLD_HOME}/be/bin_back
    mv ${DORIS_OLD_HOME}/be/lib ${DORIS_OLD_HOME}/be/lib_back

  3. 新しいバージョンの /bin および /lib ディレクトリを元のBEディレクトリにコピーします：

    cp -r ${DORIS_NEW_HOME}/be/bin ${DORIS_OLD_HOME}/be/bin
    cp -r ${DORIS_NEW_HOME}/be/lib ${DORIS_OLD_HOME}/be/lib

  4. BEノードを開始します：

    sh ${DORIS_OLD_HOME}/be/bin/start_be.sh --daemon

  5. クラスターに接続してノード情報を確認します：

    show backends\G

BEノードのaliveステータスがtrueで、Version値が新しいバージョンになっている場合、ノードのアップグレードは正常に完了しています。

ステップ3: FEノードのアップグレード​

  1. 複数FEノード構成において、アップグレード対象として非Masterノードを選択し、まずそのノードを停止します：

    sh ${DORIS_OLD_HOME}/fe/bin/stop_fe.sh

  2. FEディレクトリ内の /bin、/lib、および /mysql_ssl_default_certificate ディレクトリの名前を変更します：

    mv ${DORIS_OLD_HOME}/fe/bin ${DORIS_OLD_HOME}/fe/bin_back
    mv ${DORIS_OLD_HOME}/fe/lib ${DORIS_OLD_HOME}/fe/lib_back
    mv ${DORIS_OLD_HOME}/fe/mysql_ssl_default_certificate ${DORIS_OLD_HOME}/fe/mysql_ssl_default_certificate_back

  3. 新しいバージョンの /bin、/lib、および /mysql_ssl_default_certificate ディレクトリを元のFEディレクトリにコピーします：

    cp -r ${DORIS_NEW_HOME}/fe/bin ${DORIS_OLD_HOME}/fe/bin
    cp -r ${DORIS_NEW_HOME}/fe/lib ${DORIS_OLD_HOME}/fe/lib
    cp -r ${DORIS_NEW_HOME}/fe/mysql_ssl_default_certificate ${DORIS_OLD_HOME}/fe/mysql_ssl_default_certificate

  4. FEノードを開始します：

    sh ${DORIS_OLD_HOME}/fe/bin/start_fe.sh --daemon

  5. クラスターに接続してノード情報を確認します：

    show frontends\G

FE ノードの alive ステータスが true で、Version 値が新しいバージョンである場合、ノードのアップグレードが正常に完了しています。

  1. 他の FE ノードを順次アップグレードし、最後に Master ノードをアップグレードします。

ステップ 4: レプリカ修復とバランス機能の有効化​

アップグレードが完了し、すべての BE ノードのステータスが Alive になった後、クラスターのレプリカ修復とバランス機能を有効にします：

admin set frontend config("disable_balance" = "false");
admin set frontend config("disable_colocate_balance" = "false");
admin set frontend config("disable_tablet_scheduler" = "false");