メインコンテンツまでスキップ

クラスター操作

podがクラッシュした際にコンテナに入る方法​

k8s環境では、予期しない問題により、サービスがCrashLoopBackOff状態に入ることがあります。指定されたnamespace下でのpodステータスとpod_nameは、kubectl get pod --namespace ${namespace}コマンドで確認できます。

この状態では、describeコマンドやlogsコマンドを使用するだけでは、サービス問題の原因を特定できません。サービスがCrashLoopBackOff状態に入った場合、サービスをデプロイするpodをrunning状態に入れて、ユーザーがexecを通じてコンテナに入ってデバッグできる仕組みが必要です。

Doris OperatorはDebug実行モードを提供します。以下では、サービスがCrashLoopBackOffに入った際に手動デバッグのためにDebugモードに入る方法と、問題解決後に正常起動状態に戻る方法について説明します。

Debugモードの開始​

サービスのpodが通常動作中にCrashLoopBackOffに入った場合や正常に開始できない場合は、以下の手順でサービスをDebugモードにして、手動でサービスを開始して問題を見つけます。

  1. 以下のコマンドを使用して、問題のあるpodにannotationを追加します。
$ kubectl annotate pod ${pod_name} --namespace ${namespace} apache.org.doris/runmode=debug

サービスが次回再起動されるとき、サービスはDebugモード起動を識別するアノテーションを検出し、Debugモードに入って起動し、podステータスはrunningになります。

  1. サービスがDebugモードに入ると、サービスのpodは正常な状態で表示されます。ユーザーは以下のコマンドでpodの内部に入ることができます
$ kubectl --namespace ${namespace} exec -ti ${pod_name} bash
  1. Debugでサービスを手動で開始する。ユーザーがpodに入る際、対応する設定ファイルのポートを変更してstart_xx.shスクリプトを手動で実行する。スクリプトディレクトリは/opt/apache-doris/xx/bin下にある。

FEはquery_portを変更する必要があり、BEはheartbeat_service_portを変更する必要がある 主な目的は、Debugモードでクラッシュしたノードにサービス経由でアクセスすることによるフローの誤解を回避することである。

Debugモードの終了​

サービスが問題を特定した場合、Debug操作を終了する必要がある。この時、以下のコマンドに従って対応するpodを削除するだけで、サービスは通常モードで開始される。

$ kubectl delete pod ${pod_name} --namespace ${namespace}
Tip

podに入った後、対応するDorisコンポーネントを手動で起動する前に、設定ファイルのポート情報を変更する必要があります。

  • FEはquery_port=9030設定を変更する必要があります。デフォルトパス: /opt/apache-doris/fe/conf/fe.conf
  • BEはheartbeat_service_port=9050設定を変更する必要があります。デフォルトパス: /opt/apache-doris/be/conf/be.conf

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

このドキュメントでは、Doris Operatorデプロイメントに基づくApache Dorisクラスターをアップデートを使用してアップグレードする方法について説明します。

従来の方法でデプロイされたクラスターのアップグレードと同様に、Doris OperatorによってデプロイされたDorisクラスターでも、BEからFEノードへのローリングアップグレードが必要です。Doris OperatorはKubernetesのPerforming a Rolling Updateに基づいてローリングアップグレード機能を提供します。

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

  • アップグレード作業は、オフピーク時間帯に実行することを推奨します。
  • ローリングアップグレードプロセス中、クローズされたノードへの接続は失敗し、リクエストが失敗する原因となります。この種のビジネスでは、クライアントにリトライ機能を追加することを推奨します。
  • アップグレード前に、General Upgrade Manualを読むことで、アップグレード中の原理と注意事項を理解するのに役立ちます。
  • アップグレード前にデータとメタデータの互換性を検証することはできません。そのため、クラスターアップグレードでは、クラスター内のデータの単一コピーと単一のFE FOLLOWERノードを避ける必要があります。
  • アップグレードプロセス中にノードが再起動されるため、不要なクラスターバランシングとレプリカ修復ロジックがトリガーされる可能性があります。以下のコマンドで事前にシャットダウンしてください。
admin set frontend config("disable_balance" = "true");
admin set frontend config("disable_colocate_balance" = "true");
admin set frontend config("disable_tablet_scheduler" = "true");
  • Dorisをアップグレードする際は、2つ以上のキーノードバージョンを跨いでアップグレードしないという原則に従ってください。複数のキーノードバージョンを跨いでアップグレードしたい場合は、まず最新のキーノードバージョンにアップグレードし、その後順次アップグレードしてください。非キーノードバージョンの場合は、スキップしても構いません。詳細については、Upgrade Version Instructionsを参照してください

アップグレード操作​

アップグレードプロセスにおけるノードタイプの順序は以下の通りです。特定のタイプのノードが存在しない場合は、スキップされます：

   cn/be -> fe -> broker

対応するクラスターコンポーネントのimageを順次変更し、設定を適用することを推奨します。現在のタイプのコンポーネントが完全にアップグレードされ、ステータスが正常に戻った後、次のタイプのノードのローリングアップグレードを実行できます。

BEのアップグレード​

クラスターのcrd（Doris Operatorが定義するDorisClusterタイプリソース名の略称）ファイルを保持している場合、設定ファイルを変更しkubectl applyコマンドを実行することでアップグレードできます。

  1. spec.beSpec.imageを変更

apache/doris:be-2.1.8をapache/doris:be-2.1.9に変更

$ vim doriscluster-sample.yaml
  1. 変更を保存し、アップグレード対象の変更を適用します：
$ kubectl apply -f doriscluster-sample.yaml -n doris

kubectl edit dcrを通じて直接変更することもできます。

  1. namespace doris配下のdcrリストを確認して、更新が必要なcluster_nameを取得します。
$ kubectl get dcr -n doris
NAME                  FESTATUS    BESTATUS    CNSTATUS
doriscluster-sample   available   available
  1. 変更、保存、および反映
$ kubectl edit dcr doriscluster-sample -n doris

テキストエディタを開いた後、spec.beSpec.image を見つけて、apache/doris:be-2.1.8 を apache/doris:be-2.1.9 に変更します

  1. アップグレードプロセスと結果を確認する：
$ kubectl get pod -n doris

全てのPodが再構築されRunning状態になると、アップグレードが完了します。

FEのアップグレード​

クラスターのcrd（Doris Operatorが定義するDorisClusterタイプリソース名の略語）ファイルを保持している場合、設定ファイルを変更してkubectl applyコマンドを実行することでアップグレードできます。

  1. spec.feSpec.imageを変更する

apache/doris:fe-2.1.8をapache/doris:fe-2.1.9に変更する

$ vim doriscluster-sample.yaml
  1. 変更を保存し、アップグレードする変更を適用します：
$ kubectl apply -f doriscluster-sample.yaml -n doris

また、kubectl edit dcrを通じて直接変更することもできます。

  1. 変更、保存して有効化
$ kubectl edit dcr doriscluster-sample -n doris

テキストエディタに入った後、spec.feSpec.image を見つけて apache/doris:fe-2.1.8 を apache/doris:fe-2.1.9 に変更します

  1. アップグレードプロセスと結果を確認する：
$ kubectl get pod -n doris

すべてのPodが再構築され、Running状態になると、アップグレードが完了します。

アップグレード完了後​

クラスターノードの状態を確認する​

Access Doris Clusterドキュメントで提供されている方法で、mysql-clientを通じてDorisにアクセスします。

show frontendsやshow backendsなどのSQLを使用して、各コンポーネントのバージョンと状態を確認します。

mysql> show frontends\G;
*************************** 1. row ***************************
              Name: fe_13c132aa_3281_4f4f_97e8_655d01287425
              Host: doriscluster-sample-fe-0.doriscluster-sample-fe-internal.doris.svc.cluster.local
       EditLogPort: 9010
          HttpPort: 8030
         QueryPort: 9030
           RpcPort: 9020
ArrowFlightSqlPort: -1
              Role: FOLLOWER
          IsMaster: false
         ClusterId: 1779160761
              Join: true
             Alive: true
 ReplayedJournalId: 2422
     LastStartTime: 2024-02-19 06:38:47
     LastHeartbeat: 2024-02-19 09:31:33
          IsHelper: true
            ErrMsg:
           Version: doris-2.1.0
  CurrentConnected: Yes
*************************** 2. row ***************************
              Name: fe_f1a9d008_d110_4780_8e60_13d392faa54e
              Host: doriscluster-sample-fe-2.doriscluster-sample-fe-internal.doris.svc.cluster.local
       EditLogPort: 9010
          HttpPort: 8030
         QueryPort: 9030
           RpcPort: 9020
ArrowFlightSqlPort: -1
              Role: FOLLOWER
          IsMaster: true
         ClusterId: 1779160761
              Join: true
             Alive: true
 ReplayedJournalId: 2423
     LastStartTime: 2024-02-19 06:37:35
     LastHeartbeat: 2024-02-19 09:31:33
          IsHelper: true
            ErrMsg:
           Version: doris-2.1.0
  CurrentConnected: No
*************************** 3. row ***************************
              Name: fe_e42bf9da_006f_4302_b861_770d2c955a47
              Host: doriscluster-sample-fe-1.doriscluster-sample-fe-internal.doris.svc.cluster.local
       EditLogPort: 9010
          HttpPort: 8030
         QueryPort: 9030
           RpcPort: 9020
ArrowFlightSqlPort: -1
              Role: FOLLOWER
          IsMaster: false
         ClusterId: 1779160761
              Join: true
             Alive: true
 ReplayedJournalId: 2422
     LastStartTime: 2024-02-19 06:38:17
     LastHeartbeat: 2024-02-19 09:31:33
          IsHelper: true
            ErrMsg:
           Version: doris-2.1.0
  CurrentConnected: No
3 rows in set (0.02 sec)

FEノードのAliveステータスがtrueで、Versionの値が新しいバージョンであれば、FEノードのアップグレードは成功です。

mysql> show backends\G;
*************************** 1. row ***************************
              BackendId: 10002
                   Host: doriscluster-sample-be-0.doriscluster-sample-be-internal.doris.svc.cluster.local
          HeartbeatPort: 9050
                 BePort: 9060
               HttpPort: 8040
               BrpcPort: 8060
     ArrowFlightSqlPort: -1
          LastStartTime: 2024-02-19 06:37:56
          LastHeartbeat: 2024-02-19 09:32:43
                  Alive: true
   SystemDecommissioned: false
              TabletNum: 14
       DataUsedCapacity: 0.000
     TrashUsedCapcacity: 0.000
          AvailCapacity: 12.719 GB
          TotalCapacity: 295.167 GB
                UsedPct: 95.69 %
         MaxDiskUsedPct: 95.69 %
     RemoteUsedCapacity: 0.000
                    Tag: {"location" : "default"}
                 ErrMsg:
                Version: doris-2.1.0
                 Status: {"lastSuccessReportTabletsTime":"2024-02-19 09:31:48","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false}
HeartbeatFailureCounter: 0
               NodeRole: mix
*************************** 2. row ***************************
              BackendId: 10003
                   Host: doriscluster-sample-be-1.doriscluster-sample-be-internal.doris.svc.cluster.local
          HeartbeatPort: 9050
                 BePort: 9060
               HttpPort: 8040
               BrpcPort: 8060
     ArrowFlightSqlPort: -1
          LastStartTime: 2024-02-19 06:37:35
          LastHeartbeat: 2024-02-19 09:32:43
                  Alive: true
   SystemDecommissioned: false
              TabletNum: 8
       DataUsedCapacity: 0.000
     TrashUsedCapcacity: 0.000
          AvailCapacity: 12.719 GB
          TotalCapacity: 295.167 GB
                UsedPct: 95.69 %
         MaxDiskUsedPct: 95.69 %
     RemoteUsedCapacity: 0.000
                    Tag: {"location" : "default"}
                 ErrMsg:
                Version: doris-2.1.0
                 Status: {"lastSuccessReportTabletsTime":"2024-02-19 09:31:43","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false}
HeartbeatFailureCounter: 0
               NodeRole: mix
*************************** 3. row ***************************
              BackendId: 11024
                   Host: doriscluster-sample-be-2.doriscluster-sample-be-internal.doris.svc.cluster.local
          HeartbeatPort: 9050
                 BePort: 9060
               HttpPort: 8040
               BrpcPort: 8060
     ArrowFlightSqlPort: -1
          LastStartTime: 2024-02-19 08:50:36
          LastHeartbeat: 2024-02-19 09:32:43
                  Alive: true
   SystemDecommissioned: false
              TabletNum: 0
       DataUsedCapacity: 0.000
     TrashUsedCapcacity: 0.000
          AvailCapacity: 12.719 GB
          TotalCapacity: 295.167 GB
                UsedPct: 95.69 %
         MaxDiskUsedPct: 95.69 %
     RemoteUsedCapacity: 0.000
                    Tag: {"location" : "default"}
                 ErrMsg:
                Version: doris-2.1.0
                 Status: {"lastSuccessReportTabletsTime":"2024-02-19 09:32:04","lastStreamLoadTime":-1,"isQueryDisabled":false,"isLoadDisabled":false}
HeartbeatFailureCounter: 0
               NodeRole: mix
3 rows in set (0.01 sec)

BE ノードの Alive ステータスが true で、Version 値が新しいバージョンである場合、BE ノードのアップグレードは成功です。

クラスターレプリカ同期とバランシングの復元​

各ノードのステータスが正しいことを確認した後、以下の SQL を実行してクラスターバランシングとレプリカ修復を復元します：

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

metadata_failure_recoveryモードでのFE起動​

Frontend（FE）サービスがリーダーを選出できずに利用不可能になった場合、最も高いVLSNを持つノードを選択し、復旧メカニズムを使用してマスターとして強制起動することでクラスターを復旧できます。

コンテナ化環境での復旧モードでの起動​

  1. 最も高いVLSNを持つノードを特定する
    Kubernetesでは、FE Podが起動するたびに、そのノードの最新10件のVLSNレコードが出力されます。以下に例を示します：

    the annotations value:
    the value not equal!  debug
    /opt/apache-doris/fe/doris-meta/bdb/je.info.0:19:2025-08-05 03:42:47.650 UTC INFO [fe_f35530c4_3ff1_48fe_80d1_cc8e32dbc942] Replica-feeder fe_d8763579_92da_4d72_8c58_4e62b88bdff0 start stream at VLSN: 30
    /opt/apache-doris/fe/doris-meta/bdb/je.info.0:21:2025-08-05 03:42:47.659 UTC INFO [fe_f35530c4_3ff1_48fe_80d1_cc8e32dbc942] Replica initialization completed. Replica VLSN: -1  Heartbeat master commit VLSN: 49  DTVLSN:0 Replica VLSN delta: 50
    [Tue Aug  5 06:14:05 UTC 2025] start with meta run start_fe.sh with additional options: '--console'

この例では、ログのプレフィックス start stream at VLSN: で示されているように、現在のノードの最高 VLSN は 30 です。 2. 最高 VLSN を持つ Pod をリカバリ用に指定する
最高 VLSN を持つノードに対応する Pod を特定した後、リカバリメカニズムを有効にするためにアノテーションを付けます：

```
kubectl annotate pod {podName} "selectdb.com.doris/recovery=true"
```

再起動時に、Podは自動的に--metadata_failure_recoveryフラグを起動コマンドに追加し、リカバリモードで開始されます。 3. リカバリ後にアノテーションを削除する
FEサービスが正常に動作している場合は、今後の再起動時に予期しない動作を避けるため、手順2で追加したアノテーションを必ず削除してください。

注意
  1. アノテーションを追加した後は、kubectl delete podを使用してPodを再起動しないでください。これによりアノテーションが削除されてしまいます。代わりに、kubeletに自動的に再起動させるか、コンテナ内のプロセスを手動で強制終了してください。
  2. FEをmetadata_failure_recoveryモードで開始すると、大量のログ再生により時間がかかる場合があります。実行前に、FEサービスのstartup probe timeoutを増加し、リカバリ起動を開始する前にすべてのFE Podを削除してください。
Report issue
ASF
Resources
Community
Join the community
Copyright © 2026 The Apache Software Foundation,Licensed under the Apache License, Version 2.0. Apache, Doris, Apache Doris, the Apache feather logo and the Apache Doris logo are trademarks of The Apache Software Foundation.