データ操作のエラー
このドキュメントでは、Doris の使用中に発生するデータ操作に関する一般的な問題をまとめています。内容は随時更新します。
Q1. FE のパブリック IP アドレスに対して Stream Load でデータをインポートすると、内部ネットワークの IP アドレスにリダイレクトされるのはなぜですか？
Stream Load の接続先が FE の HTTP ポートである場合、FE は BE ノードをランダムに選び、HTTP 307 リダイレクトを行います。そのため、リクエストは実際には FE が指定した BE に送信されます。リダイレクト先には BE の IP アドレス、つまり内部ネットワークの IP アドレスが返されます。FE のパブリック IP アドレスにリクエストを送信した場合、内部ネットワークのアドレスにリダイレクトされて接続できないことがあります。
一般的な対処方法は、内部ネットワークの IP アドレスにアクセスできるようにすることです。または、すべての BE の前段にロードバランサーを配置し、Stream Load のリクエストをロードバランサーに直接送信します。ロードバランサーはリクエストを BE ノードに透過的に転送します。
Q2. Doris ではカラム名を変更できますか？
バージョン 1.2.0 以降では、"light_schema_change"="true" オプションが有効な場合にカラム名を変更できます。
バージョン 1.2.0 より前、または "light_schema_change"="true" オプションが有効でない場合、カラム名の変更はサポートされません。理由は次のとおりです。
Doris では、データベース名、テーブル名、パーティション名、マテリアライズドビュー（Rollup）名のほか、カラムの型、コメント、デフォルト値などを変更できます。しかし、カラム名の変更は現在サポートされていません。
過去の実装上の理由により、カラム名は現在、データファイルに直接書き込まれています。Doris はクエリ時にもクラス名を使って対応するカラムを探します。そのため、カラム名の変更は単純なメタデータの変更では済まず、データの書き換えも伴うため、負荷の大きい操作になります。
将来的に、互換性を保ちながら軽量にカラム名を変更できる方法がサポートされる可能性はあります。
Q3. Unique Key モデルのテーブルでマテリアライズドビューを作成できますか？
サポートされません。
Unique Key モデルのテーブルは、業務データを扱いやすいテーブルです。主キーに基づいて重複を排除するため、変更頻度の高い業務データベースを容易に同期できます。そのため、Doris にデータを取り込む際に、まず Unique Key モデルを検討するユーザーも多くいます。
しかし、Unique Key モデルのテーブルにはマテリアライズドビューを作成できません。マテリアライズドビューは、データを事前に計算し、その計算結果をクエリ時に直接返すことでクエリを高速化する仕組みだからです。事前計算されたデータは通常、sum や count などの集計値です。この場合、更新や削除によってデータが変わると、事前計算されたデータには明細情報が残っていないため、同期して更新できません。たとえば合計値が 5 の場合、元の値は 1+4 かもしれませんし、2+3 かもしれません。明細情報が失われているため、合計値がどのように計算されたかを区別できず、更新に対応できません。
Q4. tablet writer write failed, tablet_id=27306172, txn_id=28573520, err=-235 or -238
このエラーは通常、データのインポート中に発生します。エラーコード -235 は、対応するタブレットのデータバージョン数が上限（デフォルトは 500、BE パラメータ max_tablet_version_num で制御）を超えたことを意味し、それ以降の書き込みは拒否されます。質問のエラーは、タブレット 27306172 のデータバージョン数が上限を超えたことを示しています。
通常はインポート頻度が高すぎて、バックエンドのデータに対するコンパクションの速度を上回り、バージョンが蓄積して上限を超えることが原因です。この場合、まず show tablet 27306172 ステートメントを実行し、その結果に表示される show proc ステートメントを実行して、タブレットの各レプリカの状態を確認します。結果の versionCount はバージョン数を表します。バージョン数が多すぎるレプリカが見つかった場合は、インポート頻度を下げるかインポートを停止し、バージョン数が減るか確認します。インポート停止後も減らない場合は、対応する BE ノードの be.INFO ログでタブレット ID と compaction キーワードを検索し、コンパクションが正常に実行されているか確認します。コンパクションの調整については、ApacheDoris 公式アカウントの記事「Doris のベストプラクティス - コンパクションの調整（3）」を参照してください。
-238 エラーは通常、同じバッチでインポートするデータ量が多すぎて、タブレットの Segment ファイル数が上限（デフォルトは 200、BE パラメータ max_segment_num_per_rowset で制御）を超えた場合に発生します。この場合は、バッチごとのインポートデータ量を減らすか、BE の設定パラメータ値を適切に引き上げることを推奨します。バージョン 2.0 以降では、BE の設定で enable_segcompaction=true を指定して Segment Compaction 機能を有効にし、Segment ファイル数を減らすこともできます。
Q5. tablet 110309738 has few replicas: 1, alive backends: [10003]
このエラーはクエリまたはインポート中に発生することがあり、通常は対応するタブレットのレプリカに異常があることを意味します。
まず show backends コマンドで BE ノードが停止していないか確認します。たとえば、isAlive フィールドが false の場合や、LastStartTime が最近の時刻である場合（直近で再起動したことを示します）です。BE が停止している場合は、対応するノードの be.out ログを確認します。異常が原因で BE が停止した場合、通常は be.out に例外のスタックトレースが出力され、問題の調査に役立ちます。be.out にエラーのスタックトレースがない場合は、Linux コマンド dmesg -T を使い、OOM によってシステムがプロセスを強制終了したか確認できます。
停止している BE ノードがない場合は、show tablet 110309738 ステートメントを実行し、その結果に表示される show proc ステートメントを実行して、各タブレットレプリカの状態をさらに調査します。
Q6. disk xxxxx on backend xxx exceed limit usage
通常はインポートや Alter などの操作中に発生します。このエラーは、対応する BE のディスク使用率がしきい値（デフォルトは 95%）を超えたことを意味します。まず show backends コマンドを実行します。MaxDiskUsedPct には、対応する BE で最も使用率が高いディスクの使用率が表示されます。この値が 95% を超えると、エラーが報告されます。
対応する BE ノードでデータディレクトリの使用状況を確認します。trash ディレクトリと snapshot ディレクトリは手動で削除して空き容量を確保できます。データディレクトリが多くの容量を占めている場合は、一部のデータを削除して空き容量を確保することを検討してください。詳しくは、ディスク容量管理を参照してください。
Q7. Java プログラムから Stream Load で大量のデータを一度のバッチでインポートすると、Broken Pipe エラーが発生することがあります。
Broken Pipe 以外にも、さまざまなエラーが発生する場合があります。
この状況は通常、httpv2 を有効にした後に発生します。httpv2 は Spring Boot で実装された HTTP サービスで、デフォルトの組み込みコンテナーとして Tomcat を使用します。しかし、Tomcat による 307 リダイレクトの処理に問題があるとみられたため、後に組み込みコンテナーが Jetty に変更されました。また、Java プログラムで使用する Apache HttpClient は 4.5.13 より後のバージョンにする必要があります。それ以前のバージョンでもリダイレクトの処理に問題がありました。
この問題には、次の対処方法があります。
-
httpv2 を無効にする
fe.conf に enable_http_server_v2=false を追加し、FE を再起動します。ただし、新しいバージョンの UI や、httpv2 を使用する一部の新しいインターフェースは利用できなくなります（通常のインポートとクエリには影響しません）。
-
アップグレードする
Doris 0.15 以降にアップグレードすると、この問題は解消されます。
Q8. インポートやクエリ中にエラー -214 が報告される
インポートやクエリなどの操作中に、次のエラーが発生することがあります。
failed to initialize storage reader. tablet=63416.1050661139.aa4d304e7a7aff9c-f0fa7579928c85a0, res=-214, backend=192.168.100.10
-214 エラーは、対応するタブレットのデータバージョンが欠落していることを意味します。上記のエラーは、192.168.100.10 の BE にあるタブレット 63416 のレプリカでデータバージョンが欠落していることを示します（ほかにも同様のエラーコードがあり、以下の方法で確認および修復できます）。
バージョン 4.0.8 以降、スキャンフェーズのエラーには failed to initialize storage reader というプレフィックスが一律には付かなくなりました。実際の下位層のエラーメッセージをそのまま残し、. tablet=... backend=... のみを末尾に追加します。
リーダーの初期化時には、プッシュダウンされた式を評価するために最初の行も先読みします。そのため、データのエラーや式のエラーもこの処理経路に到達し、従来のプレフィックスが付くとストレージ層の障害に見えていました。-214 の調査では、プレフィックスの文字列ではなく、エラーコードと tablet= / backend= の情報を確認してください。
通常、データに複数のレプリカがある場合、システムは問題のあるレプリカを自動的に修復します。次の手順で調査できます。
まず show tablet 63416 ステートメントを実行し、その結果に表示される show proc xxx ステートメントを実行して、対応するタブレットの各レプリカの状態を確認します。通常、確認すべきなのは Version カラムの値です。
通常、タブレットの複数のレプリカの Version は同じであり、対応するパーティションの VisibleVersion とも一致します。
対応するパーティションのバージョンは show partitions from tblx で確認できます（タブレットに対応するパーティションは show tablet ステートメントで確認できます）。
また、show proc ステートメントの CompactionStatus カラムに表示される URL をブラウザーで開くと、より詳しいバージョン情報を確認でき、欠落しているバージョンを特定できます。
長時間経っても自動修復されない場合は、show proc "/cluster_balance" ステートメントで、システムが現在実行しているタブレットの修復タスクとスケジューリングタスクを確認します。スケジューリング待ちのタブレットが多数あり、修復に時間がかかっている可能性があります。pending_tablets と running_tablets の記録を確認してください。
さらに、admin repair ステートメントを使い、テーブルまたはパーティションを指定して優先的に修復できます。詳しくは help admin repair を参照してください。
それでも修復できず、レプリカが複数ある場合は、admin set replica status コマンドで問題のあるレプリカを強制的にオフラインにします。詳しくは、help admin set replica status にある、レプリカのステータスを bad に設定する例を参照してください（bad に設定したレプリカにはアクセスされなくなり、その後自動的に修復されます。ただし、操作前にほかのレプリカが正常であることを確認してください）。
Q9. Not connected to 192.168.100.1:8060 yet, server_id=384
このエラーは、インポートやクエリの際に発生することがあります。対応する BE のログにも、同様のエラーが記録されている場合があります。
これは RPC エラーで、通常は次の可能性があります。1. 対応する BE ノードが停止している。2. RPC の輻輳またはその他のエラーが発生している。
BE ノードが停止している場合は、停止した具体的な原因を調べる必要があります。ここでは RPC の輻輳についてのみ説明します。
一つ目は OVERCROWDED です。これは、RPC の送信元で未送信データが大量にたまり、しきい値を超えたことを意味します。関連する BE パラメータは次のとおりです。
brpc_socket_max_unwritten_bytes：デフォルト値は 1GB です。未送信データがこの値を超えると、エラーが報告されます。この値を適切に変更すると、OVERCROWDED エラーを回避できます（ただし、輻輳そのものは解消されないため、根本的な解決にはなりません）。tablet_writer_ignore_eovercrowded：デフォルトは false です。true に設定すると、Doris はインポート中の OVERCROWDED エラーを無視します。このパラメータは主に、インポートの失敗を回避し、インポートの安定性を高めるために使用します。
二つ目は、RPC パケットのサイズが max_body_size を超える場合です。クエリに非常に大きな String 型または bitmap 型の値が含まれると、この問題が発生する可能性があります。次の BE パラメータを変更すると回避できます。
brpc_max_body_size：default 3GB.
Q10. [ Broker load ] org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe
インポート中に org.apache.thrift.transport.TTransportException: java.net.SocketException: Broken pipe が発生します。
外部ストレージ（HDFS など）からデータをインポートする際、ディレクトリ内のファイル数が多すぎると、ファイル一覧の取得に時間がかかることが原因として考えられます。ここでの Broker RPC Timeout はデフォルトで 10 秒なので、タイムアウトを適切に延長する必要があります。
fe.conf 設定ファイルを編集し、次のパラメータを追加します。
broker_timeout_ms = 10000
##The default here is 10 seconds, you need to increase this parameter appropriately
パラメータの追加後は、FE サービスを再起動する必要があります。
Q11. [ Routine load ] ReasonOfStateChanged: ErrorReason{code=errCode = 104, msg='be 10004 abort task with reason: fetch failed due to requested offset not available on the broker: Broker: Offset out of range'}
この問題が発生する理由は、Kafka のクリーンアップポリシーのデフォルトが 7 日間であるためです。何らかの理由で Routine Load タスクが一時停止し、長期間再開されなかった場合、タスクを再開した時点で、Routine Load が記録していた消費オフセットに対応するデータが Kafka によって削除されていると、この問題が発生します。
この問題は alter routine load で解決できます。
Kafka の最小オフセットを確認し、ALTER ROUTINE LOAD コマンドでオフセットを変更して、タスクを再開します。
ALTER ROUTINE LOAD FOR db.tb
FROM kafka
(
"kafka_partitions" = "0",
"kafka_offsets" = "xxx",
"property.group.id" = "xxx"
);
Q12. ERROR 1105 (HY000): errCode = 2, detailMessage = (192.168.90.91)[CANCELLED][INTERNAL_ERROR]error setting certificate verify locations: CAfile: /etc/ssl/certs/ca-certificates.crt CApath: none
yum install -y ca-certificates
ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /etc/ssl/certs/ca-certificates.crt
Q13. create partition failed. partition numbers will exceed limit variable max_auto_partition_num
自動パーティションテーブルへのデータのインポート時に、誤って多数のパーティションが作成されることを防ぐため、FE の設定項目 max_auto_partition_num で、このようなテーブルに自動作成できるパーティション数の上限を制御します。さらに多くのパーティションを作成する必要がある場合は、FE Master ノードのこの設定項目を変更してください。