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

運用・保守エラー

このドキュメントは、主にDorisの使用中に発生する運用・保守の一般的な問題を記録するために使用されます。随時更新されます。

このドキュメントに記載されているBEバイナリの名前は doris_be ですが、以前のバージョンでは palo_be でした。

Q1. DECOMMISSIONを通じてBEノードをログオフする際、なぜ常にいくつかのタブレットが残るのですか？​

オフライン処理中に、show backendsを使用してオフラインノードのtabletNumを確認すると、tabletNumの数が減少していることが観察できます。これは、データシャードがこのノードから移行されていることを示しています。数が0になると、システムは自動的にノードを削除します。しかし、場合によっては、tabletNumが特定の値まで下がった後に変化しなくなることがあります。これは通常、2つの理由が考えられます：

  1. タブレットは、削除されたばかりのテーブル、パーティション、またはマテリアライズドビューに属しています。削除されたばかりのオブジェクトはごみ箱に残ります。オフラインロジックはこれらのシャードを処理しません。オブジェクトがごみ箱に存在する時間は、FE設定パラメータcatalog_trash_expire_secondを変更することで修正できます。これらのタブレットは、オブジェクトがごみ箱から削除されたときに処理されます。
  2. これらのタブレットの移行タスクに問題があります。この場合、show proc show proc "/cluster_balance"を通じて特定のタスクのエラーを確認する必要があります。

上記の状況については、まず show proc "/cluster_health/tablet_health"; を通じてクラスター内に不健全なシャードがあるかどうかを確認できます。0の場合、drop backend文を通じて直接BEを削除できます。そうでなければ、不健全なシャードのレプリカも詳細に確認する必要があります。

Q2. priorty_networkはどのように設定すべきですか？​

priorty_networkは、FEとBE両方の設定パラメータです。このパラメータは主に、システムが正しいネットワークカードIPを自身のIPとして選択するのに役立ちます。後続のマシンに新しいネットワークカードを追加することによって引き起こされる間違ったIP選択の問題を防ぐため、いずれの場合でもこのパラメータを明示的に設定することをお勧めします。

priorty_networkの値はCIDR形式で表現されます。2つの部分に分かれており、最初の部分はドット付き10進表記のIPアドレス、2番目の部分はプレフィックス長です。例えば、10.168.1.0/8はすべての10.xx.xx.xx IPアドレスにマッチし、10.168.1.0/16はすべての10.168.xx.xx IPアドレスにマッチします。

特定のIPを直接指定するのではなくCIDR形式を使用する理由は、すべてのノードが統一された設定値を使用できるようにするためです。例えば、10.168.10.1と10.168.10.2という2つのノードがある場合、priorty_networkの値として10.168.10.0/24を使用できます。

Q3. FEのMaster、Follower、Observerとは何ですか？​

まず、FEには2つの役割のみがあることを明確にします：FollowerとObserver。MasterはFollowerノードのグループから選択されたFEにすぎません。MasterはFollowerの特別な種類と見なすことができます。そのため、クラスターにいくつのFEがあり、それらの役割は何かと尋ねられたとき、正しい答えはすべてのFEノード数、Follower役割の数、Observer役割の数であるべきです。

Follower役割のすべてのFEノードは選択可能グループを形成し、Paxos合意プロトコルのグループ概念に似ています。グループ内でFollowerがMasterとして選出されます。Masterがダウンすると、新しいFollowerが自動的にMasterとして選択されます。ObserverはMasterになることはないため、選出には参加しません。

メタデータログは、成功とみなされるためにはほとんどのFollowerノードで正常に書き込まれる必要があります。例えば、3つのFEがある場合、2つだけが正常に書き込まれます。これがFollower役割の数が奇数である必要がある理由です。

Observerの役割はこの単語の意味と同じです。正常に書き込まれたメタデータログを同期し、メタデータ読み取りサービスを提供する観察者としてのみ機能します。多数決書き込みのロジックには関与しません。

通常、1 Follower + 2 ObserverまたはFollower + N Observerを展開できます。前者は運用・保守が簡単で、フォロワー間で複雑なエラー状況を引き起こすような一貫性合意がほとんどありません（ほとんどの会社がこの方法を使用）。後者はメタデータ書き込みの高可用性を保証できます。高並行クエリシナリオの場合、Observerを適切に追加できます。

Q4. ノードに新しいディスクを追加したのに、なぜデータが新しいディスクにバランスされないのですか？​

現在のDorisバランシング戦略はノードベースです。つまり、ノードの全体的な負荷指標（シャード数と総ディスク使用率）に応じてクラスター負荷が判断されます。そして、高負荷ノードから低負荷ノードへデータシャードを移行します。各ノードがディスクを追加した場合、ノードの全体的な観点から負荷は変化しないため、バランシングロジックがトリガーされません。

さらに、Dorisは現在、単一ノード内のディスク間でのバランシング操作をサポートしていません。したがって、新しいディスクを追加した後、データは新しいディスクにバランスされません。

しかし、ノード間でデータが移行される際、Dorisはディスクを考慮に入れます。例えば、シャードがノードAからノードBに移行される場合、ノードBでディスク容量使用率の低いディスクが優先的に選択されます。

ここでは、この問題を解決する3つの方法を提供します：

  1. 新しいテーブルの再構築

    create table like文を通じて新しいテーブルを作成し、insert into selectメソッドを使用して古いテーブルから新しいテーブルにデータを同期します。新しいテーブルが作成されると、新しいテーブルのデータシャードが新しいディスクに分散されるため、データも新しいディスクに書き込まれます。この方法は、データ量が少ない場合（数十GB以内）に適しています。

  2. Decommissionコマンドを通じて

    decommissionコマンドは、BEノードを安全に廃止するために使用されます。このコマンドは、まずノード上のデータシャードを他のノードに移行し、その後ノードを削除します。前述したように、データ移行中は、ディスク使用率の低いディスクが優先されるため、この方法はデータを他のノードのディスクに「強制的に」移行できます。データ移行が完了したら、decommission操作をキャンセルして、データがこのノードに再バランスされるようにします。すべてのBEノードで上記の手順を実行すると、データはすべてのノードのすべてのディスクに均等に分散されます。

    decommissionコマンドを実行する前に、オフライン後にノードが削除されることを避けるため、次のコマンドを実行してください。

    admin set frontend config("drop_backend_after_decommission" = "false");

  3. APIを使用した手動データ移行

    DorisはHTTP APIを提供しており、あるディスク上のデータシャードを別のディスクに手動で移行することを指定できます。

Q5. FE/BEログを正しく読み取るにはどうすればよいですか？​

多くの場合、ログを通じて問題のトラブルシューティングを行う必要があります。ここでは、FE/BEログの形式と表示方法について説明します。

  1. FE

    FEログには主に以下が含まれます：

    • fe.log: メインログ。fe.out以外のすべてを含みます。
    • fe.warn.log: メインログのサブセット、WARNおよびERRORレベルのログのみが記録されます。
    • fe.out: 標準/エラー出力（stdoutおよびstderr）のログ。
    • fe.audit.log: 監査ログ、このFEが受信したすべてのSQLリクエストを記録します。

    典型的なFEログは以下のとおりです：

    2021-09-16 23:13:22,502 INFO (tablet scheduler|43) [BeLoadRebalancer.selectAlternativeTabletsForCluster():85] cluster is balance: default_cluster with medium: HDD.skip

  • 2021-09-16 23:13:22,502: ログ時刻。

    • INFO: ログレベル、デフォルトはINFO。
    • (tablet scheduler|43): スレッド名とスレッドID。スレッドIDを通じて、このスレッドのコンテキスト情報を確認し、このスレッドで何が発生したかをチェックできます。
    • BeLoadRebalancer.selectAlternativeTabletsForCluster():85: クラス名、メソッド名、コード行番号。
    • cluster is balance xxx: ログ内容。

    通常、主にfe.logログを確認します。特殊なケースでは、一部のログがfe.outに出力される場合があります。

  1. BE

    BEログには主に以下が含まれます：

    • be.INFO: メインログ。これは実際にはソフトリンクで、最新のbe.INFO.xxxxに接続されています。
    • be.WARNING: メインログのサブセットで、WARNとFATALレベルのログのみが記録されます。これは実際にはソフトリンクで、最新のbe.WARN.xxxxに接続されています。
    • be.out: 標準/エラー出力（stdoutとstderr）のログ。

    典型的なBEログは以下の通りです：

    I0916 23:21:22.038795 28087 task_worker_pool.cpp:1594] finish report TASK. master host: 10.10.10.10, port: 9222

  • I0916 23:21:22.038795: ログレベルと日時。大文字のIはINFO、WはWARN、FはFATALを意味します。

    • 28087: スレッドID。スレッドIDを通じて、このスレッドのコンテキスト情報を確認し、このスレッドで何が起こったかを確認できます。
    • task_worker_pool.cpp:1594: コードファイルと行番号。
    • finish report TASK xxx: ログ内容。

    通常、主にbe.INFOログを確認します。BE停止などの特殊な場合には、be.outを確認する必要があります。

Q6. FE/BEノードがダウンした場合のトラブルシューティング方法は？​

  1. BE

    BEプロセスはC/C++プロセスであり、プログラムバグ（メモリ境界外アクセス、不正アドレスアクセスなど）やOut Of Memory (OOM)のために停止する可能性があります。この場合、以下の手順でエラーの原因を確認できます：

    1. be.outを確認

      BEプロセスは、例外によりプログラムが終了する際に、現在のエラースタックをbe.out（be.INFOやbe.WARNINGではなく、be.outであることに注意）に出力します。エラースタックを通じて、通常はプログラムが問題を起こした箇所について大まかな情報を得ることができます。

      be.outにエラースタックがある場合は、通常プログラムバグが原因であり、一般ユーザーが自分で解決することは困難な場合があることに注意してください。WeChatグループ、github discussionまたはdev mail groupでサポートを求め、対応するエラースタックを投稿することで、迅速に問題のトラブルシューティングを行うことができます。

    2. dmesg

      be.outにスタック情報がない場合、OOMによってシステムに強制終了された可能性が高いです。この場合、dmesg -Tコマンドを使用してLinuxシステムログを確認できます。最後にMemory cgroup out of memory: Kill process 7187 (doris_be) score 1007 or sacrifice childのようなログが表示された場合、OOMが原因であることを意味します。

      メモリ問題には、大きなクエリ、インポート、compactionなど多くの理由が考えられます。Dorisもメモリ使用量の最適化を継続的に行っています。WeChatグループ、github discussionまたはdev mail groupでサポートを求めてください。

    3. be.INFOでFで始まるログがあるかどうかを確認。

      Fで始まるログはFatalログです。例えば、F0916は9月16日のFatalログを示しています。Fatalログは通常プログラムアサーションエラーを示し、アサーションエラーはプロセスを直接終了させます（プログラムのバグを示しています）。WeChatグループ、github discussionまたはdev mail groupでサポートを求めてください。

  2. FE

    FEはjavaプロセスで、C/C++プログラムより堅牢性が高いです。通常、FEが停止する理由はOOM（Out-of-Memory）またはメタデータ書き込み失敗の可能性があります。これらのエラーは通常、fe.logまたはfe.outにエラースタックが記録されます。エラースタック情報に基づいて詳細な調査が必要です。

Q7. データディレクトリのSSDとHDDの設定について、テーブル作成時にFailed to find enough host with storage medium and tagエラーが発生​

Dorisは1つのBEノードに複数のストレージパスを設定することをサポートしています。通常、各ディスクに1つのストレージパスを設定できます。同時に、DorisはSSDやHDDなど、パスに指定するストレージメディアプロパティをサポートしています。SSDは高速ストレージデバイス、HDDは低速ストレージデバイスを表します。

クラスターが全てHDDまたは全てSSDなど、1種類のメディアのみを持つ場合、ベストプラクティスはbe.confでメディアプロパティを明示的に指定しないことです。上記のFailed to find enough host with storage medium and tagエラーが発生した場合、一般的にはbe.confでSSDメディアのみを設定しているのに、テーブル作成段階でproperties {"storage_medium" = "hdd"}を明示的に指定していることが原因です。同様に、be.confでHDDメディアのみを設定していて、テーブル作成段階でproperties {"storage_medium" = "ssd"}を明示的に指定した場合も同じエラーが発生します。解決策は、テーブル作成のpropertiesパラメータを設定に合わせて変更するか、be.confでSSD/HDDの明示的な設定を削除することです。

パスのストレージメディアプロパティを指定することで、Dorisのホット・コールドデータパーティションストレージ機能を活用して、パーティションレベルでホットデータをSSDに保存し、コールドデータは自動的にHDDに転送されます。

Dorisはストレージパスが配置されているディスクの実際のストレージメディアタイプを自動認識しないことに注意が必要です。このタイプは、ユーザーがパス設定で明示的に示す必要があります。例えば、パス"/path/to/data1.SSD"は、このパスがSSDストレージメディアであることを意味します。そして"data1.SSD"が実際のディレクトリ名です。Dorisはディレクトリ名の後の".SSD"接尾辞に基づいてストレージメディアタイプを判断し、実際のストレージメディアタイプではありません。つまり、ユーザーは任意のパスをSSDストレージメディアとして指定でき、Dorisはディレクトリ接尾辞のみを認識し、ストレージメディアが一致するかどうかは判断しません。接尾辞が記述されていない場合、デフォルトでHDDになります。

言い換えれば、".HDD"と".SSD"はストレージディレクトリの「相対的な」「低速」と「高速」を識別するためのもので、実際のストレージメディアタイプではありません。したがって、BEノードのストレージパスにメディアの違いがない場合、接尾辞を記入する必要はありません。

Q8. NginxでWeb UIロードバランシングを実装する際に複数のFEにログインできない​

Dorisは複数のFEを展開できます。Web UIにアクセスする際、Nginxをロードバランシングに使用すると、セッション問題により継続的にログインを求められます。この問題は実際にはセッション共有の問題です。Nginxは一元的なセッション共有ソリューションを提供します。ここではnginxのip_hash技術を使用し、ip_hashによって1つのipのリクエストを同じバックエンドに転送できるため、このipの下でクライアントとバックエンドが安定したセッションを確立できます。ip_hashはupstream設定で定義されます：

upstream doris.com {
   server 172.22.197.238:8030 weight=3;
   server 172.22.197.239:8030 weight=4;
   server 172.22.197.240:8030 weight=4;
   ip_hash;
}

完全なNginxの設定例は以下の通りです：

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;

events {
    worker_connections 1024;
}

http {
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
    #include /etc/nginx/custom/*.conf;
    upstream doris.com {
      server 172.22.197.238:8030 weight=3;
      server 172.22.197.239:8030 weight=4;
      server 172.22.197.240:8030 weight=4;
      ip_hash;
    }

    server {
        listen 80;
        server_name gaia-pro-bigdata-fe02;
        if ($request_uri ~ _load) {
           return 307 http://$host$request_uri ;
        }

        location / {
            proxy_pass http://doris.com;
            proxy_redirect default;
        }
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
            root html;
        }
    }
 }

Q9. FEの起動に失敗し、fe.logに「wait catalog to be ready. FE type UNKNOWN」が継続的に表示される​

この問題には通常2つの原因があります：

  1. 今回のFE起動時に取得されたローカルIPが前回の起動時と一致しない。通常はpriority_networkが正しく設定されていないため、FE起動時に間違ったIPアドレスにマッチしてしまうことが原因です。priority_networkを修正後、FEを再起動してください。
  2. クラスタ内のほとんどのFollower FEノードが起動されていない。例えば、3つのFollowerがあるうち1つしか起動されていない場合です。この場合、少なくとも他に1つのFEを起動する必要があり、そうすることでFE選出可能グループがMasterを選出してサービスを提供できるようになります。

上記の状況で解決できない場合は、Doris公式サイトドキュメントのmetadata operation and maintenance documentに従って復旧できます。

Q10. Lost connection to MySQL server at 'reading initial communication packet', system error: 0​

MySQLクライントを使用してDorisに接続する際に以下の問題が発生する場合、これは通常FEのコンパイル時に使用したjdkバージョンとFE実行時に使用するjdkバージョンが異なることが原因です。dockerを使用してイメージをコンパイルする場合、デフォルトのJDKバージョンはopenjdk 11であり、コマンドを通じてopenjdk 8に切り替えることができることに注意してください（詳細はコンパイルドキュメントを参照）。

Q11. recoveryTracker should overlap or follow on disk last VLSN of 4,422,880 recoveryFirst= 4,422,882 UNEXPECTED_STATE_FATAL​

FEを再起動する際に上記のエラーが発生することがあります（通常は複数のFollowerがある場合のみ）。エラー内の2つの値は2だけ異なり、FEの起動が失敗します。

これはbdbjeのバグで、まだ解決されていません。この場合は、Metadata Operation and Maintenance Documentationの障害復旧操作を実行してメタデータを復旧するしかありません。

Q12. DorisコンパイルとインストールのJDKバージョン非互換性問題​

Dockerを使用してDorisをコンパイルし、コンパイル・インストール後にFEを起動すると、例外メッセージjava.lang.Suchmethoderror: java.nio.ByteBuffer.limit (I)Ljava/nio/ByteBuffer;が表示されます。これはDocker内のデフォルトがJDK 11であるためです。インストール環境でJDK8を使用している場合は、Docker内のJDK環境をJDK8に切り替える必要があります。具体的な切り替え方法については、Compile Documentationを参照してください。

Q13. FEの起動エラーまたはローカルでのunit test実行時のError Cannot find external parser table action_table.dat​

以下のコマンドを実行してください

cd fe && mvn clean install -DskipTests

同じエラーが報告された場合は、以下のコマンドを実行してください

cp fe-core/target/generated-sources/cup/org/apache/doris/analysis/action_table.dat fe-core/target/classes/org/apache/doris/analysis

Q14. DorisがバージョンKONSIDR1.0以降にアップグレードし、ODBC経由でのMySQL接続で「Failed to set ciphers to use (2026)」エラーが報告される問題​

この問題は、dorisがバージョン1.0にアップグレードし、Connector/ODBC 8.0.x以上を使用した後に発生します。Connector/ODBC 8.0.xには、yum経由でインストールされる/usr/lib64/libmyodbc8w.soなど複数のアクセス方法があり、これはlibssl.so.10とlibcrypto.so.10に依存しています。 doris 1.0以降では、opensslがバージョン1.1にアップグレードされ、dorisバイナリパッケージに組み込まれているため、opensslの競合が発生し、以下のようなエラーが生じる可能性があります

ERROR 1105 (HY000): errCode = 2, detailMessage = driver connect Error: HY000 [MySQL][ODBC 8.0(w) Driver]SSL connection error: Failed to set ciphers to use (2026)

解決策は、ODBC ConnectorのConnector/ODBC 8.0.28バージョンを使用し、オペレーティングシステムでLinux - Genericを選択することです。このバージョンのODBC Driverはopenssl version 1.1を使用します。または、より低いバージョンのODBC connector、例えばConnector/ODBC 5.3.14を使用してください。詳細については、ODBC exterior documentationを参照してください。

MySQL ODBC Driverで使用されているopensslのバージョンは以下の方法で確認できます

ldd /path/to/libmyodbc8w.so |grep libssl.so

出力にlibssl.so.10が含まれている場合は使用時に問題が発生する可能性があり、libssl.so.1.1が含まれている場合はdoris 1.0と互換性があります

Q14. バージョン1.2にアップグレード後、BEのNoClassDefFoundErrorによる起動失敗問題​

Java UDF依存関係エラー アップグレードサポートがbeを開始する場合、以下のJava NoClassDefFoundErrorエラーが発生します

Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/doris/udf/IniUtil
Caused by: java.lang.ClassNotFoundException: org.apache.doris.udf.JniUtil

公式ウェブサイトから apache-doris-java-udf-jar-with-dependencies-1.2.0 のJava UDF関数依存パッケージをダウンロードし、BE インストールディレクトリ下の lib ディレクトリに配置してから、BE を再起動する必要があります

Q15. バージョン1.2にアップグレード後、BE起動時に Failed to initialize JNI が表示される​

アップグレード後にBEを起動する際に以下の Failed to initialize JNI エラーが発生する場合

Failed to initialize JNI: Failed to find the library libjvm.so.

JAVA_HOME環境変数を設定するか、be.confでJAVA_HOME変数を設定してBEノードを再起動する必要があります。

Q16. Docker: backendの起動に失敗する​

これはCPUがAVX2をサポートしていないことが原因の可能性があります。docker logs -f beでbackendログを確認してください。 CPUがAVX2をサポートしていない場合は、apache/doris:1.2.2-be-x86_64の代わりに、 apache/doris:1.2.2-be-x86_64-noavx2イメージを使用する必要があります。 イメージのバージョン番号は時間の経過とともに変更されることに注意してください。最新バージョンについてはDockerhubを確認してください。

このページでは