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

データ操作エラー

このドキュメントは主に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の場合、プリ計算されたデータは詳細情報を失っているため、同期的に更新できません。例えば、sumの値5は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設定で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エラーを無視します。このパラメータは主にインポートの失敗を避け、インポートの安定性を向上させるためのものです。

二つ目は、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のcleanup policyがデフォルトで7日間であることです。routine loadタスクが何らかの理由で一時停止され、長時間タスクが復元されない場合、タスクが再開されるときに、routine loadは消費offsetを記録しますが、kafkaが対応するoffsetをクリーンアップしてしまったときにこの問題が発生します

そのため、この問題はalter routine loadで解決できます：

kafkaの最小offsetを確認し、ALTER ROUTINE LOADコマンドを使用してoffsetを修正し、タスクを再開してください

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​

auto-partitionedテーブルにデータをインポートする際に、誤って多数のpartitionが作成されることを防ぐため、FE設定項目max_auto_partition_numを使用してこのようなテーブルに対して自動作成されるpartitionの最大数を制御しています。本当により多くのpartitionを作成する必要がある場合は、FE Masterノードのこの設定項目を変更してください。

このページでは