クラスターのアップグレード
Dorisは、FEおよびBEノードの段階的なアップグレードを可能にし、ダウンタイムを最小限に抑え、アップグレードプロセス中にシステムの運用を継続できるローリングアップグレード機能を提供します。
バージョン互換性
Dorisのバージョニングは3つの構成要素で構成されています。1桁目は主要マイルストーンバージョンを表し、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 注を確認して、互換性の問題を特定してください。
-
クラスター内のタスクにリトライメカニズムを追加: アップグレード中はノードが順次再起動されます。タスクの失敗を避けるために、クエリタスクとStream Loadインポートジョブにリトライメカニズムが配置されていることを確認してください。flink-doris-connectorまたはspark-doris-connectorを使用するRoutine Loadジョブには、既にコード内にリトライメカニズムが含まれており、追加のロジックは必要ありません。
-
レプリカ修復およびバランス機能の無効化: アップグレードプロセス中はこれらの機能を無効にしてください。アップグレードの結果に関係なく、アップグレード完了後にこれらの機能を再有効化してください。
メタデータ互換性テスト
本番環境では、高可用性のために少なくとも3つのFEノードを構成することを推奨します。FEノードが1つしかない場合は、アップグレード前にメタデータ互換性テストを実行する必要があります。メタデータ互換性は、非互換性がアップグレードの失敗とデータ損失を引き起こす可能性があるため、重要です。各アップグレード前にメタデータ互換性テストを実施することを推奨しますが、以下の点に留意してください。
-
FEノードの使用を避けるため、可能な限り開発マシンまたはBEノードでメタデータ互換性テストを実行してください。
-
FEノードでテストを実施する必要がある場合は、非Masterノードを使用し、元のFEプロセスを停止してください。
アップグレード前に、メタデータ非互換性による失敗を防ぐためにメタデータ互換性テストを実施してください。
-
メタデータ情報のバックアップ:
アップグレードを開始する前に、Master FEノードのメタデータをバックアップしてください。
show frontendsコマンドを使用し、IsMaster列を参照してMaster FEノードを特定してください。FEメタデータは、FEノードを停止することなくホットバックアップできます。デフォルトでは、FEメタデータはfe/doris-metaディレクトリに保存されます。これは、fe.conf設定ファイルのmeta_dirパラメータで確認できます。 -
テスト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 clusterID
clusterId=<a_new_clusterID, such as 123456>
...
-
バックアップされたMaster FEメタデータを新しい互換性テスト環境にコピーします。
cp ${DORIS_OLD_HOME}/fe/doris-meta/* ${DORIS_NEW_HOME}/fe/doris-meta -
コピーしたメタデータディレクトリ内の
VERSIONファイルを編集して、cluster_idを新しいクラスターIDに更新します。例えば、次の例に示すように123456に変更します:vi ${DORIS_NEW_HOME}/fe/doris-meta/image/VERSION
clusterId=123456 -
テスト環境で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
-
上記で述べたクエリポート
19030を使用するなど、MySQLコマンドを使用して現在のFEに接続することで、FEプロセスが正常に開始されたことを確認します。mysql -uroot -P19030 -h127.0.0.1
アップグレード手順
アップグレードの詳細なプロセスは以下の通りです:
-
レプリカ修復およびバランス機能を無効化
-
BEノードをアップグレード
-
FEノードをアップグレード
-
レプリカ修復およびバランス機能を有効化
アップグレードプロセス中は、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");
ステップ2: BEノードのアップグレード
データの安全性を確保するため、3つのレプリカを使用してデータを保存し、アップグレードの誤りや失敗によるデータ損失を回避してください。
-
マルチレプリカクラスターでは、1つのBEノードでプロセスを停止し、段階的なアップグレードを実行することを選択できます:
sh ${DORIS_OLD_HOME}/be/bin/stop_be.sh -
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 -
新しいバージョンの
/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 -
BEノードを開始します:
sh ${DORIS_OLD_HOME}/be/bin/start_be.sh --daemon -
クラスターに接続してノード情報を確認します:
show backends\G
BEノードのaliveステータスがtrueで、Version値が新しいバージョンになっている場合、そのノードのアップグレードは正常に完了しています。
Step 3: FEノードのアップグレード
-
複数FEノード構成では、アップグレード対象として非Masterノードを選択し、まずそのノードを停止します:
sh ${DORIS_OLD_HOME}/fe/bin/stop_fe.sh -
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 -
新しいバージョンの
/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 -
FEノードを開始します:
sh ${DORIS_OLD_HOME}/fe/bin/start_fe.sh --daemon -
クラスターに接続してノード情報を確認します:
show frontends\G
FEノードのaliveステータスがtrueで、Versionの値が新しいバージョンの場合、そのノードは正常にアップグレードされています。
- 他の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");