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

データ操作エラー

このドキュメントは主に Doris の使用中のデータ操作に関する一般的な問題を記録するために使用され、随時更新されます。

Q1. Stream Load を使用して FE のパブリックネットワークアドレスにアクセスしてデータをインポートしたが、イントラネット 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 などの集計指標です。この時、update や delete などのデータ変更があった場合、事前計算されたデータは詳細情報を失っているため、同期的に更新することができません。例えば、5 という sum 値は 1+4 または 2+3 である可能性があります。詳細情報が失われているため、この合計値がどのように計算されたかを区別できないので、更新の要件を満たすことができません。

Q4. tablet writer write failed, tablet_id=27306172, txn_id=28573520, err=-235 または -238​

このエラーは通常、データインポート操作中に発生します。エラーコードは -235 です。このエラーの意味は、対応する tablet のデータバージョンが最大限度（デフォルト 500、BE パラメータ max_tablet_version_num によって制御）を超え、後続の書き込みが拒否されることです。例えば、質問のエラーは tablet 27306172 のデータバージョンが限度を超えていることを意味します。

このエラーは通常、インポート頻度が高すぎて、バックエンドデータの compaction 速度を上回り、バージョンが蓄積されて最終的に限度を超えることが原因です。この時、まず show tablet 27306172 文を実行し、次に結果の show proc 文を実行して tablet の各コピーの状態を確認できます。結果の versionCount はバージョン数を表します。コピーのバージョンが多すぎることが判明した場合は、インポート頻度を減らすかインポートを停止し、バージョン数が減少するかを観察する必要があります。インポートを停止した後もバージョン数が減少しない場合は、対応する BE ノードに行って be.INFO ログを確認し、tablet id と compaction キーワードを検索して、compaction が正常に実行されているかを確認する必要があります。compaction のチューニングについては、ApacheDoris 公式アカウントの記事を参照してください：Doris Best Practices - Compaction Tuning (3)

-238 エラーは通常、同じバッチのインポートデータが大きすぎて、tablet の Segment ファイルが多すぎる（デフォルトは 200、BE パラメータ max_segment_num_per_rowset によって制御）場合に発生します。この時、一度にインポートするデータ量を減らすか、BE 設定パラメータ値を適切に増加させて問題を解決することをお勧めします。バージョン 2.0 以降、ユーザーは BE config で enable_segcompaction=true を設定することで segment compaction 機能を有効にして segment ファイル数を削減できます。

Q5. tablet 110309738 has few replicas: 1, alive backends: [10003]​

このエラーはクエリまたはインポート操作中に発生する可能性があります。通常、対応する tablet のコピーに例外があることを意味します。

この時、まず show backends コマンドを使用して BE ノードがダウンしているかを確認できます。例えば、isAlive フィールドが false であるか、LastStartTime が最近の時間（最近再起動されたことを示す）である場合です。BE がダウンしている場合は、BE に対応するノードに行って be.out ログを確認する必要があります。BE が異常な理由でダウンした場合、通常 be.out に例外スタックが印刷され、問題のトラブルシューティングに役立ちます。be.out にエラースタックがない場合は、linux コマンド dmesg -T を使用して、プロセスが OOM のためにシステムによってキルされたかを確認できます。

BE ノードがダウンしていない場合は、show tablet 110309738 文を実行し、次に結果の show proc 文を実行して各 tablet コピーの状態を確認し、さらなる調査を行う必要があります。

Q6. Java プログラムを通じて stream load を呼び出してデータをインポートする際、データのバッチが大きい場合に Broken Pipe エラーが発生する可能性があります。​

Broken Pipe 以外にも、他の奇妙なエラーが発生する可能性があります。

この状況は通常 httpv2 を有効にした後に発生します。httpv2 は spring boot を使用して実装された http サービスで、tomcat をデフォルトの組み込みコンテナとして使用しているためです。しかし、tomcat の 307 転送の処理にいくつかの問題があるようで、後に組み込みコンテナが jetty に変更されました。さらに、java プログラムの apache http client のバージョンは 4.5.13 以降のバージョンを使用する必要があります。以前のバージョンでは、転送の処理にもいくつかの問題がありました。

そのため、この問題は 2 つの方法で解決できます：

  1. httpv2 を無効にする

    fe.conf に enable_http_server_v2=false を追加した後、FE を再起動します。ただし、新しいバージョンの UI インターフェースは使用できなくなり、httpv2 に基づくいくつかの新しいインターフェースも使用できません。（通常のインポートクエリは影響を受けません）。

  2. アップグレード

    Doris 0.15 以降にアップグレードすることで、この問題は修正されています。

Q7. インポートとクエリ時にエラー -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のコピーのデータバージョンが欠落していることを示しています。（他にも類似のエラーコードがある場合がありますが、以下の方法で確認・修復できます）。

通常、データに複数のコピーがある場合、システムは自動的にこれらの問題のあるコピーを修復します。以下の手順でトラブルシューティングできます：

まず、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に設定後、そのコピーはアクセスされなくなります。そして後で自動的に修復されます。ただし、操作前に他のコピーが正常であることを確認してください）

Q8. Not connected to 192.168.100.1:8060 yet, server_id=384​

インポートやクエリ時にこのエラーに遭遇する場合があります。対応するBEログを確認すると、類似のエラーが見つかる場合もあります。

これはRPCエラーであり、通常2つの可能性があります：1. 対応するBEノードがダウンしている。2. rpcの輻輳またはその他のエラー。

BEノードがダウンしている場合は、具体的なダウンタイムの理由を確認する必要があります。ここではrpc輻輳の問題のみを議論します。

一つのケースはOVERCROWDEDで、rpcソースに閾値を超える大量の未送信データがあることを意味します。BEには関連する2つのパラメータがあります：

  1. brpc_socket_max_unwritten_bytes：デフォルト値は1GBです。未送信データがこの値を超えるとエラーが報告されます。この値を適切に修正してOVERCROWDEDエラーを回避できます。（ただし、これは対症療法であり、本質的には輻輳が依然として存在します）。
  2. tablet_writer_ignore_eovercrowded：デフォルトはfalseです。trueに設定すると、DorisはインポートでちゅうのOVERCROWDEDエラーを無視します。このパラメータは主にインポートの失敗を回避し、インポートの安定性を向上させるためのものです。

2つ目は、rpcのパケットサイズがmax_body_sizeを超える場合です。この問題は、クエリに非常に大きなString型やbitmap型がある場合に発生する可能性があります。以下のBEパラメータを修正することで回避できます：

brpc_max_body_size：default 3GB.

Q9. [ 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サービスの再起動が必要です。

Q10. [ 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"
);

Q11. 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

Q12. create partition failed. partition numbers will exceed limit variable max_auto_partition_num​

自動パーティション化されたテーブルのデータインポート時に誤って大量のパーティションが作成されることを防ぐため、FE設定項目max_auto_partition_numを使用して、そのようなテーブルに自動的に作成されるパーティションの最大数を制御しています。より多くのパーティションを作成する必要がある場合は、FE Masterノードのこの設定項目を変更してください。

このページでは