このドキュメントは主にDorisの使用中にデータ操作で発生する一般的な問題を記録するために使用されます。随時更新されます。
stream loadの接続先がFEのhttpポートの場合、FEはランダムにBEノードを選択してhttp 307リダイレクト操作を実行するため、ユーザーのリクエストは実際にFEによって割り当てられたBEに送信されます。リダイレクトはBEのIP、つまりイントラネットIPを返します。そのため、FEのパブリックIPを通じてリクエストを送信すると、内部ネットワークアドレスにリダイレクトされるため接続できない可能性が非常に高くなります。
通常の方法は、イントラネットIPアドレスにアクセスできることを確認するか、すべてのBE上位層にロードバランサーを配置し、stream loadリクエストを直接ロードバランサーに送信して、ロードバランサーがリクエストをBEノードに透過的に送信するようにすることです。
バージョン1.2.0以降、"light_schema_change"="true"オプションが有効になっている場合、カラム名を変更できます。
バージョン1.2.0以前、または"light_schema_change"="true"オプションが有効になっていない場合、カラム名の変更はサポートされていません。理由は以下の通りです：
Dorisはデータベース名、テーブル名、パーティション名、マテリアライズドビュー（Rollup）名、およびカラムタイプ、コメント、デフォルト値などの変更をサポートしています。しかし残念ながら、カラム名の変更は現在サポートされていません。
歴史的な理由により、カラム名は現在データファイルに直接書き込まれています。Dorisがクエリを実行する際も、クラス名を通じて対応するカラムを見つけます。そのため、カラム名の変更は単純なメタデータの変更だけでなく、データの書き換えも含む非常に重い操作です。
将来的に軽量なカラム名変更操作をサポートするための互換性のある手段を排除するものではありません。
サポートしていません。
Unique Keyモデルのテーブルはビジネスフレンドリーなテーブルです。プライマリキーによる重複除去のユニークな機能により、頻繁に変更されるデータを持つビジネスデータベースを簡単に同期できます。そのため、多くのユーザーはDorisにデータをアクセスする際、最初にUnique Keyモデルの使用を検討します。
しかし残念ながら、Unique Keyモデルのテーブルはマテリアライズドビューを作成できません。理由は、マテリアライズドビューの本質が事前計算によってデータを「事前計算」し、クエリ時に計算されたデータを直接返すことでクエリを高速化することだからです。マテリアライズドビューでは、「事前計算」されたデータは通常、sumやcountなどの集約指標です。この時、updateやdeleteなどのデータ変更が発生すると、事前計算されたデータは詳細情報を失っているため、同期的に更新することができません。例えば、5というsum値は1+4または2+3である可能性があります。詳細情報の損失により、この合計値がどのように計算されたかを区別できないため、更新の要求を満たすことができません。
このエラーは通常データインポート操作中に発生します。エラーコードは-235です。このエラーの意味は、対応するタブレットのデータバージョンが最大制限（デフォルト500、BEパラメータmax_tablet_version_numで制御）を超え、後続の書き込みが拒否されることです。例えば、質問のエラーはタブレット27306172のデータバージョンが制限を超えていることを意味します。
このエラーは通常、インポート頻度が高すぎて、バックエンドデータのcompaction速度を上回り、バージョンが蓄積されて最終的に制限を超えることによって引き起こされます。この時点で、まずshow tablet 27306172文を使用し、結果のshow proc文を実行してタブレットの各コピーの状態を確認できます。結果のversionCountはバージョン数を表します。コピーのバージョンが多すぎることがわかった場合は、インポート頻度を減らすかインポートを停止してバージョン数が減少するかを観察する必要があります。インポートを停止してもバージョン数が減少しない場合は、対応するBEノードに移動してbe.INFOログを表示し、tablet idとcompactionキーワードを検索して、compactionが正常に実行されているかを確認する必要があります。compactionチューニングについては、ApacheDoris公式アカウント記事を参照してください：Doris Best Practices - Compaction Tuning (3)
-238エラーは通常、同じバッチのインポートデータが大きすぎて、タブレットのSegmentファイルが多すぎる（デフォルトは200、BEパラメータmax_segment_num_per_rowsetで制御）場合に発生します。この時、一度にインポートするデータ量を減らすか、BE設定パラメータ値を適切に増加させて問題を解決することをお勧めします。バージョン2.0以降、ユーザーはBE configでenable_segcompaction=trueを設定してsegment compaction機能を有効にし、segmentファイル数を削減できます。
このエラーはクエリまたはインポート操作中に発生する可能性があります。通常、対応するタブレットのコピーに例外があることを意味します。
この時点で、まずshow backendsコマンドを使用してBEノードがダウンしているかを確認できます。例えば、isAliveフィールドがfalseであるか、LastStartTimeが最近の時刻である（最近再起動されたことを示す）場合です。BEがダウンしている場合は、BEに対応するノードに移動してbe.outログを確認する必要があります。BEが異常な理由でダウンした場合、通常be.outに例外スタックが印刷されて問題のトラブルシューティングに役立ちます。be.outにエラースタックがない場合は、linuxコマンドdmesg -Tを使用して、プロセスがOOMのためにシステムによってkillされたかを確認できます。
BEノードがダウンしていない場合は、show tablet 110309738文を使用し、結果のshow proc文を実行して各タブレットコピーの状態を確認してさらに調査する必要があります。
通常、Import、Alterなどの操作で発生します。このエラーは、BEに対応する対応するディスクの使用量がしきい値（デフォルト95%）を超えていることを意味します。この場合、まずshow backendsコマンドを使用でき、MaxDiskUsedPctは対応するBEで最も使用量の多いディスクの使用量を示します。95%を超える場合、このエラーが報告されます。
この時点で、対応するBEノードに移動してデータディレクトリの使用量を確認する必要があります。trashディレクトリとsnapshotディレクトリは手動でクリーニングしてスペースを解放できます。データディレクトリが大きなスペースを占有している場合は、一部のデータを削除してスペースを解放することを検討する必要があります。詳細については、Disk Space Managementを参照してください。
Broken Pipe以外にも、他の奇妙なエラーが発生する可能性があります。
この状況は通常httpv2を有効にした後に発生します。httpv2はspring bootを使用して実装されたhttpサービスで、tomcatをデフォルトの組み込みコンテナとして使用するためです。しかし、tomcatの307転送の処理にはいくつかの問題があるようで、後で組み込みコンテナはjettyに変更されました。さらに、javaプログラムのapache http clientのバージョンは4.5.13以降のバージョンを使用する必要があります。以前のバージョンでは、転送の処理にもいくつかの問題がありました。
そのため、この問題は2つの方法で解決できます：
httpv2を無効にする
fe.confに enable_http_server_v2=false を追加してFEを再起動します。ただし、新しいバージョンのUIインターフェースは使用できなくなり、httpv2ベースの一部の新しいインターフェースも使用できません。（通常のインポートクエリは影響を受けません）。
アップグレード
Doris 0.15以降にアップグレードすると、この問題は修正されています。
インポート、クエリなどの操作を実行する際に、次のエラーが発生する可能性があります：
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 に設定すると、そのコピーはアクセスされなくなります。後で自動的に修復されます。ただし、操作前に他のコピーが正常であることを確認してください）
インポートやクエリ時にこのエラーに遭遇する可能性があります。対応する BE ログを確認すると、同様のエラーが見つかる場合もあります。
これは RPC エラーであり、通常2つの可能性があります：1. 対応する BE ノードがダウンしている。2. rpc の輻輳またはその他のエラー。
BE ノードがダウンしている場合は、具体的なダウン理由を確認する必要があります。ここでは rpc 輻輳の問題のみを説明します。
1つのケースは OVERCROWDED で、rpc ソースに閾値を超える大量の未送信データがあることを意味します。BE にはこれに関連する2つのパラメータがあります：
brpc_socket_max_unwritten_bytes：デフォルト値は 1GB です。未送信データがこの値を超えるとエラーが報告されます。OVERCROWDED エラーを回避するために、この値を適切に変更できます。（ただし、これは対症療法であり、本質的には輻輳が残っています）。tablet_writer_ignore_eovercrowded：デフォルトは false です。true に設定すると、Doris はインポート中の OVERCROWDED エラーを無視します。このパラメータは主にインポート失敗を回避し、インポートの安定性を向上させるためのものです。2つ目は、rpc のパケットサイズが max_body_size を超えることです。この問題は、クエリに非常に大きな String 型や bitmap 型がある場合に発生する可能性があります。以下の BE パラメータを変更することで回避できます：
brpc_max_body_size：default 3GB.
インポート時に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サービスの再起動が必要です。
この問題の原因は、Kafkaのcleanupポリシーがデフォルトで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" );
yum install -y ca-certificates ln -s /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt /etc/ssl/certs/ca-certificates.crt
自動パーティションテーブルのデータインポート時に誤って過剰なパーティションが作成されることを防ぐため、FE設定項目max_auto_partition_numを使用してそのようなテーブルに自動的に作成されるパーティションの最大数を制御しています。より多くのパーティションを作成する必要がある場合は、FE MasterノードのこのConfig項目を変更してください。