データレプリカの管理
このドキュメントはクラスター管理者向けです。Apache Doris のレプリカのバランシングと修復の仕組み、スケジューリングの優先度、レプリカの状態を確認する方法、レプリカの異常やクラスター負荷の偏りに対処する際の一般的な運用方法を説明します。
バージョン 0.9.0 以降、Doris には最適化されたレプリカ管理戦略が導入され、レプリカの状態を確認するためのツールも充実しました。このドキュメントでは、レプリカのスケジューリングの原則を理解し、レプリカの破損、ノードの停止、ディスク使用量の偏りなどが発生した場合にクラスターを迅速に復旧する方法を説明します。
Colocation 属性を持つテーブルのレプリカ修復とバランシングについては、Colocate Join を参照してください。
適用シナリオ
| シナリオ | 参照先 |
|---|---|
| レプリカのスケジューリング原則を理解する | レプリカの修復、レプリカのバランシング |
| クラスター全体のレプリカの健全性を確認する | レプリカの状態の確認 |
| 特定の Tablet の異常なレプリカを特定する | Tablet 単位の状態確認 |
| BE の停止やディスク障害後に手動で復旧する | ベストプラクティス |
| 修復・バランシングの速度を調整する、またはバランシングを一時停止する | リソース制御、関連する設定 |
| クラスター負荷やディスク使用量の偏りに対処する | レプリカのバランシング |
用語
| 用語 | 意味 |
|---|---|
| Tablet | Doris テーブルの論理シャード。テーブルは複数のシャードを持ちます。 |
| Replica | シャードのコピー。デフォルトでは、各シャードに 3 つのレプリカがあります。 |
| Healthy Replica | 所属する Backend が稼働しており、バージョンが完全なレプリカ。 |
| TabletChecker (TC) | 常駐するバックグラウンドスレッド。すべての Tablet を定期的に走査して状態を確認し、その結果に基づいて Tablet を TabletScheduler に送るかどうかを判断します。 |
| TabletScheduler (TS) | 常駐するバックグラウンドスレッド。TabletChecker から送られた Tablet の修復を処理し、クラスター内のレプリカのバランシングも行います。 |
| TabletSchedCtx (TSC) | Tablet をラップするオブジェクト。TC は Tablet を選択した後、TSC にラップして TS に送ります。 |
| Storage Medium | ストレージメディア。Doris ではパーティション単位で異なるメディア（SSD と HDD）を指定できます。レプリカのスケジューリング戦略では、メディアごとに個別にスケジュールします。 |
全体の処理フローは次のとおりです。
+--------+ +-----------+
| Meta | | Backends |
+---^----+ +------^----+
| | | 3. Send clone tasks
1. Check tablets | | |
+--------v------+ +-----------------+
| TabletChecker +--------> TabletScheduler |
+---------------+ +-----------------+
2. Waiting to be scheduled
上の図は簡略化した処理フローです。TabletChecker が Tablet の状態を確認し、修復が必要な Tablet を TabletScheduler に送ります。TabletScheduler はクローンタスクを BE に割り当てます。
レプリカの状態
Tablet の複数のレプリカは、さまざまな要因によって状態が一致しなくなることがあります。Doris は不一致のあるレプリカを自動的に修復し、クラスターをできるだけ早く異常状態から復旧させようとします。
レプリカの健全性ステータス
| ステータス | 意味 |
|---|---|
| BAD | レプリカが破損しています。ディスク障害やバグなどによる回復不能な損傷を含みますが、それらに限りません。 |
| VERSION_MISSING | バージョンが欠落しています。Doris ではインポートの各バッチがデータバージョンに対応し、レプリカのデータは連続する複数のバージョンで構成されます。インポートエラーや遅延などにより、一部のレプリカでデータバージョンが不完全になることがあります。 |
| HEALTHY | 健全なレプリカです。データが正常で、レプリカが配置された BE ノードも正常な状態です（ハートビートが正常で、ノードはデコミッション中ではありません）。 |
Tablet の健全性ステータス
Tablet の健全性は、そのすべてのレプリカの状態によって決まります。ステータスは次のとおりです。
| ステータス | 意味 |
|---|---|
| REPLICA_MISSING | レプリカが不足しています。稼働中のレプリカ数が期待されるレプリカ数より少ない状態です。 |
| VERSION_INCOMPLETE | 稼働中のレプリカ数は期待される数以上ですが、健全なレプリカ数が期待される数より少ない状態です。 |
| REPLICA_RELOCATING | 完全なバージョンを持つ稼働中のレプリカ数はレプリカ数の設定値と同じですが、それらを配置した BE ノードの一部が利用できない状態です（デコミッション中など）。 |
| REPLICA_MISSING_IN_CLUSTER | 複数クラスター構成で、健全なレプリカ数は期待される数以上ですが、対応するクラスター内のレプリカ数が期待される数より少ない状態です。 |
| REDUNDANT | レプリカが冗長です。健全なレプリカはすべて対応するクラスター内にありますが、その数が期待される数を超えているか、利用できない余分なレプリカがあります。 |
| FORCE_REDUNDANT | 特殊なステータスです。「既存のレプリカ数 >= 利用可能なノード数 >= 期待されるレプリカ数」であり、かつ「稼働中のレプリカ数 < 期待されるレプリカ数」の場合にのみ発生します。この場合、新しいレプリカを作成できるノードを確保するために、先にレプリカを削除する必要があります。 |
| COLOCATE_MISMATCH | Colocation テーブル固有のシャードステータスです。シャードのレプリカ配置が Colocation Group で指定された配置と一致しません。 |
| COLOCATE_REDUNDANT | Colocation テーブル固有のシャードステータスです。テーブルのシャードレプリカが冗長です。 |
| HEALTHY | 健全なシャードです。上記 1～8 のいずれの条件にも該当しません。 |
レプリカの修復
常駐バックグラウンドプロセスである TabletChecker は、すべてのシャードの状態を定期的に確認します。異常な状態のシャードは、スケジューリングと修復のために TabletScheduler に渡されます。実際の修復は BE 上のクローンタスクで行われ、FE はクローンタスクの生成のみを担当します。
注 1: レプリカ修復では、まずレプリカを作成または補充して期待される数にそろえ、その後に冗長なレプリカを削除します。
注 2: クローンタスクとは、指定されたリモート BE から指定された宛先 BE に、指定されたデータをコピーする処理です。
ステータス別の修復方法
Doris はステータスごとに異なる修復方法を使用します。
-
REPLICA_MISSING / REPLICA_RELOCATING
負荷が低く利用可能な BE ノードを宛先に、健全なレプリカをコピー元に選びます。クローンタスクはコピー元から宛先へ完全なレプリカをコピーします。レプリカの補充では、ストレージメディアを考慮せず、利用可能な BE ノードを直接選択します。
-
VERSION_INCOMPLETE
比較的完全なレプリカを宛先に、健全なレプリカをコピー元に選びます。クローンタスクは、コピー元から宛先のレプリカへ欠落したバージョンをコピーしようとします。
-
REPLICA_MISSING_IN_CLUSTER
REPLICA_MISSING と同じ方法で処理します。
-
REDUNDANT
レプリカ修復後は、通常、シャードに冗長なレプリカが存在します。次の優先順位で削除対象のレプリカを一つ選びます。
- レプリカを配置した BE がデコミッション済み
- レプリカが破損している
- レプリカを配置した BE に到達できない、またはデコミッション中
- レプリカが CLONE 状態にある（クローンタスクの実行中の中間状態）
- レプリカのバージョンが欠落している
- レプリカが別のクラスターにある
- レプリカを配置した BE の負荷が高い
-
FORCE_REDUNDANT
REDUNDANT とは異なり、この場合は稼働中のレプリカ数が期待される数より少ないものの、新しいレプリカを作成するための追加の利用可能なノードがありません。そのため、先にレプリカを削除して、新しいレプリカを作成できるノードを確保する必要があります。削除順序は REDUNDANT と同じです。
-
COLOCATE_MISMATCH
Colocation Group のレプリカ配置で指定された BE ノードの一つを、レプリカ補充の宛先ノードとして選びます。
-
COLOCATE_REDUNDANT
Colocation Group のレプリカ配置で指定されていない BE ノード上のレプリカを削除します。
Doris はレプリカの配置先を選ぶ際、同じ Tablet のレプリカを同一ホスト上の異なる BE に配置しません。これにより、そのホスト上のすべての BE が停止しても、すべてのレプリカが失われる事態を防ぎます。
スケジューリングの優先度
TabletScheduler でスケジューリングを待つシャードには、状態に応じて異なる優先度が割り当てられます。優先度の高いシャードが先にスケジュールされます。現在の優先度は次のとおりです。
| 優先度 | 条件 |
|---|---|
| VERY_HIGH | REDUNDANT: レプリカが冗長なシャード。緊急度は最も低いものの、最も速く処理でき、ディスク容量などのリソースをすぐに解放できるため、先に処理されます。 FORCE_REDUNDANT: 上記と同じです。 |
| HIGH | REPLICA_MISSING でレプリカの大半が不足している場合（3 つのうち 2 つが失われた場合など）。 VERSION_INCOMPLETE でレプリカの大半にバージョンの欠落がある場合。 COLOCATE_MISMATCH: Colocation テーブルのシャードはできるだけ早く修復する必要があります。 COLOCATE_REDUNDANT。 |
| NORMAL | REPLICA_MISSING だがレプリカの大半が稼働している場合（3 つのうち 1 つが失われた場合など）。 VERSION_INCOMPLETE だがレプリカの大半のバージョンが完全な場合。 REPLICA_RELOCATING でレプリカの大半を移動する必要がある場合（3 つのうち 2 つなど）。 |
| LOW | REPLICA_MISSING_IN_CLUSTER。 REPLICA_RELOCATING だがレプリカの大半が安定している場合。 |
手動による優先度の指定
システムはスケジューリングの優先度を自動的に決定します。特定のテーブルやパーティションをより早く修復したい場合は、次のコマンドで優先修復を指定できます。
ADMIN REPAIR TABLE tbl [PARTITION (p1, p2, ...)];
このコマンドは TabletChecker に対し、Tablet の走査中に、優先修復が指定されたテーブルまたはパーティション内の問題のある Tablet に VERY_HIGH 優先度を付けるよう指示します。
注: このコマンドはヒントにすぎず、修復の成功は保証しません。TabletScheduler によるスケジューリングに伴い、優先度が変わる場合があります。また、Master FE の切り替えまたは再起動後、この情報は失われます。
優先指定を取り消すには、次のコマンドを使用します。
ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];
優先度の動的調整
優先度によって損傷の大きいシャードが先に修復され、システムの可用性が向上します。ただし、優先度の高い修復タスクが失敗し続けると、優先度の低いタスクがいつまでもスケジュールされない可能性があります。そのため、Doris はすべてのタスクがスケジュールされる機会を得られるよう、実行状態に基づいて優先度を動的に調整します。
- スケジューリングに 5 回連続で失敗した場合（リソースを確保できない、適切なコピー元または宛先が見つからない場合など）、優先度を下げます。
- タスクが 30 分間スケジュールされなかった場合、優先度を上げます。
- 同じ Tablet のタスクの優先度は、5 分間につき多くても一度だけ調整します。
初期優先度の重みを維持するため、次のルールを適用します。初期優先度が VERY_HIGH の場合は NORMAL までしか下がらず、LOW の場合は HIGH までしか上がりません。この動的調整は、ユーザーが手動で設定した優先度にも適用されます。
レプリカのバランシング
Doris はクラスター内のレプリカを自動的にバランシングします。現在は 負荷分散 と パーティション分散 の二つの戦略をサポートしています。
| 戦略 | 主な目的 | 適用シナリオ | 備考 |
|---|---|---|---|
| 負荷分散 | ノードのディスク使用量とレプリカ数の両方を均等にする | ディスク容量とレプリカの分布の両方を考慮する必要がある場合 | 二つの指標からスコアを計算します |
| パーティション分散 | 各パーティションのレプリカをノード間に均等に配置する | パーティションの読み書きに高い要件があり、ホットスポットを避けたい場合 | ディスク使用量は考慮しないため、ディスク容量に注意が必要です |
戦略は FE の起動前に tablet_rebalancer_type でのみ設定できます。実行中の切り替えはサポートされません。
どちらの戦略でも、同じ Tablet のレプリカが同一ホスト上の BE に配置されないようにします。
負荷分散
負荷分散では、対象のシャードについて、まず低負荷ノードにレプリカを作成し、その後、高負荷ノード上のレプリカを削除します。また、ストレージメディアの種類によって、同じクラスター内の BE ノードが一種類または二種類のメディアを持つ場合があります。メディア A を使用するシャードは、バランシング後も可能な限りメディア A に配置する必要があります。そのため、クラスター内の BE ノードをストレージメディア別に分け、各メディアの BE ノード群に対して個別に負荷分散をスケジュールします。
BE ノードの負荷
ClusterLoadStatistics (CLS) は、クラスター内の各 Backend の負荷バランスを表します。TabletScheduler はこの統計情報を使用してクラスターのバランシングを開始します。現在は、ディスク使用量 と レプリカ数 の二つの指標から各 BE の負荷スコア loadScore を計算します。スコアが高いほど、その BE の負荷が高いことを示します。
ディスク使用量とレプリカ数にはそれぞれ capacityCoefficient と replicaNumCoefficient という重み係数があり、合計は常に 1 です。
- 有効な
backend_load_capacity_coeficientパラメーター（値の範囲は0.0～1.0）が設定されている場合、capacityCoefficient = backend_load_capacity_coeficientです。 - それ以外の場合、
capacityCoefficientは実際のディスク使用量に基づいて動的に調整されます。- BE のディスク使用率全体が 50% 未満の場合、
capacityCoefficientは 0.5 です。 - ディスク使用率が 75% を超える場合（FE 設定項目
capacity_used_percent_high_waterで調整可能）、値は 1 です。 - 使用率が 50%～75% の場合、重み係数は次の式に従って滑らかに増加します。
- BE のディスク使用率全体が 50% 未満の場合、
capacityCoefficient = 2 * disk usage - 0.5
この重み係数により、ディスク使用率が高すぎる場合は Backend の負荷スコアが高くなり、BE の負荷をできるだけ早く減らせます。
TabletScheduler は CLS を 20 秒ごとに更新します。
パーティション分散
パーティション分散では、各 Backend 上の各パーティションのレプリカ数の差（パーティションの偏り）を最小化します。そのため、ディスク使用量は考慮せず、レプリカ数のみを考慮します。
移行回数を最小限に抑えるため、パーティション分散では二次元の貪欲戦略を使用し、偏りが最も大きいパーティションからバランシングします。パーティションをバランシングする際は、クラスター全体の Backend 間のレプリカ数の差（クラスターの偏り／全体の偏り）を減らす方向を選ぼうとします。
偏りの統計
偏りの統計は ClusterBalanceInfo で表されます。
partitionInfoBySkew: パーティションの偏りをキーにしてソートされ、偏りが最大のパーティションを見つけやすくします。beByTotalReplicaCount: 各 Backend の総レプリカ数をキーにしてソートされます。
ClusterBalanceInfo も CLS に保存され、20 秒ごとに更新されます。偏りが最大のパーティションが複数ある場合は、計算対象をランダムに一つ選びます。
バランシング戦略のスケジューリング
TabletScheduler は各スケジューリングラウンドで LoadBalancer を使用し、一定数の健全なシャードをバランシング候補として選びます。次のラウンドで、これらの候補シャードを対象にバランシングのスケジューリングを試みます。
リソース制御
レプリカの修復とバランシングは、いずれも BE 間でレプリカをコピーすることで行われます。同じ BE で多数のタスクを同時に実行すると、IO 負荷が大きくなります。そのため、Doris はスケジューリング時に各ノードで実行できるタスク数を制御します。
| リソース | 説明 |
|---|---|
| リソース制御の単位 | 最小単位はディスク、つまり be.conf で指定されたデータパスです。 |
| レプリカ修復用スロット | 各ディスクにはデフォルトで 2 つのスロットがあります。クローンタスクはコピー元と宛先でそれぞれ一つのスロットを使用します。空きスロットが 0 の場合、新しいタスクは割り当てられません。スロット数は FE の schedule_slot_num_per_hdd_path または schedule_slot_num_per_ssd_path で調整できます。 |
| バランシングタスク用スロット | 各ディスクには、バランシングタスク専用の独立したスロットがデフォルトで 2 つあります。修復タスクがスロットを占有しても、高負荷ノードがバランシングによって空き容量を確保できるようにするためです。 |
レプリカの状態の確認
レプリカの状態の確認は、主にレプリカ自体の状態と、レプリカ修復・バランシングタスクの実行状態を把握するために使用します。これらの状態の大部分は Master FE ノードにのみ存在する ため、以下のコマンドは Master FE に直接接続して実行する必要があります。
レプリカの状態
クラスター全体の状態確認
SHOW PROC '/cluster_health/tablet_health'; コマンドで、クラスター全体のレプリカの状態を確認できます。
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| DbId | DbName | TabletNum | HealthyNum | ReplicaMissingNum | VersionIncompleteNum | ReplicaRelocatingNum | RedundantNum | ReplicaMissingInClusterNum | ReplicaMissingForTagNum | ForceRedundantNum | ColocateMismatchNum | ColocateRedundantNum | NeedFurtherRepairNum | UnrecoverableNum | ReplicaCompactionTooSlowNum | InconsistentNum | OversizeNum | CloningNum |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
| 10005 | default_cluster:doris_audit_db | 84 | 84 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 13402 | default_cluster:ssb1 | 709 | 708 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 10108 | default_cluster:tpch1 | 278 | 278 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| Total | 3 | 1071 | 1070 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------+--------------------------------+-----------+------------+-------------------+----------------------+----------------------+--------------+----------------------------+-------------------------+-------------------+---------------------+----------------------+----------------------+------------------+-----------------------------+-----------------+-------------+------------+
主な列の説明は次のとおりです。
HealthyNum: 対応する Database 内で健全な状態にある Tablet の数。ReplicaCompactionTooSlowNum: レプリカのバージョン数が多すぎる Tablet の数。InconsistentNum: レプリカ間に不整合がある Tablet の数。Total行: クラスター全体の統計です。通常、TabletNumとHealthyNumは等しくなります。異なる場合は詳細をたどって該当する Tablet を特定できます。
たとえば、ssb1 データベースには異常な状態の Tablet が 1 つあります。次のコマンドで該当する Tablet を確認できます（13402 は対応する DbId です）。
SHOW PROC '/cluster_health/tablet_health/13402';
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| ReplicaMissingTablets | VersionIncompleteTablets | ReplicaRelocatingTablets | RedundantTablets | ReplicaMissingInClusterTablets | ReplicaMissingForTagTablets | ForceRedundantTablets | ColocateMismatchTablets | ColocateRedundantTablets | NeedFurtherRepairTablets | UnrecoverableTablets | ReplicaCompactionTooSlowTablets | InconsistentTablets | OversizeTablets |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| 14679 | | | | | | | | | | | | | |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
出力には、ReplicaMissing 状態にある異常な Tablet の ID（この例では 14679）が表示されます。次のセクションでは、特定の Tablet の各レプリカの状態を確認する方法を説明します。
テーブル（パーティション）単位の状態確認
次のコマンドで、指定したテーブルまたはパーティションのレプリカの状態を確認できます。WHERE 句を使用すると、状態で絞り込めます。たとえば、パーティション p1 と p2（テーブル tbl1）で、状態が OK のレプリカを表示するには次のようにします。
SHOW REPLICA STATUS FROM tbl1 PARTITION (p1, p2) WHERE STATUS = "OK";
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| TabletId | ReplicaId | BackendId | Version | LastFailedVersion | LastSuccessVersion | CommittedVersion | SchemaHash | VersionNum | IsBad | State | Status |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
| 29502429 | 29502432 | 10006 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502429 | 36885996 | 10002 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502429 | 48100551 | 10007 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 29502434 | 10001 | 2 | -1 | 2 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 44900737 | 10004 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
| 29502433 | 48369135 | 10006 | 2 | -1 | -1 | 1 | -1 | 2 | false | NORMAL | OK |
+----------+-----------+-----------+---------+-------------------+--------------------+------------------+------------+------------+-------+--------+--------+
すべてのレプリカの状態が表示されます。
IsBadがtrueの場合、レプリカは破損しています。Status列にはその他の状態が表示されます。詳細はHELP SHOW REPLICA STATUS;を実行してください。
SHOW REPLICA STATUS コマンドは主にレプリカの健全性を確認するために使用します。レプリカの追加情報を確認するには、次のコマンドを使用します。
SHOW TABLETS FROM tbl1;
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| TabletId | ReplicaId | BackendId | SchemaHash | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | DataSize | RowCount | State | LstConsistencyCheckTime | CheckVersion | CheckVersionHash | VersionCount | PathHash | MetaUrl | CompactionStatus |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
| 29502429 | 29502432 | 10006 | 1421156361 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -5822326203532286804 | url | url |
| 29502429 | 36885996 | 10002 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -1441285706148429853 | url | url |
| 29502429 | 48100551 | 10007 | 1421156361 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | 784 | 0 | NORMAL | N/A | -1 | -1 | 2 | -4784691547051455525 | url | url |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+
上の出力には、レプリカのサイズ、行数、バージョン数、レプリカが配置されたデータパスなどの追加情報が表示されます。
注: ここに表示される
State列は、レプリカの健全性ではなく、CLONE、SCHEMA_CHANGE、ROLLUP など、レプリカのタスク状態を示します。
また、次のコマンドで指定したテーブルまたはパーティションのレプリカ配置を確認し、配置が均等かどうかを調べられます。
SHOW REPLICA DISTRIBUTION FROM tbl1;
+-----------+------------+-------+---------+
| BackendId | ReplicaNum | Graph | Percent |
+-----------+------------+-------+---------+
| 10000 | 7 | | 7.29 % |
| 10001 | 9 | | 9.38 % |
| 10002 | 7 | | 7.29 % |
| 10003 | 7 | | 7.29 % |
| 10004 | 9 | | 9.38 % |
| 10005 | 11 | > | 11.46 % |
| 10006 | 18 | > | 18.75 % |
| 10007 | 15 | > | 15.62 % |
| 10008 | 13 | > | 13.54 % |
+-----------+------------+-------+---------+
出力には、テーブル tbl1 のレプリカが各 BE ノードに配置されている数と割合、および簡易的なグラフが表示されます。
Tablet 単位の状態確認
特定の Tablet を調べるには、次のコマンドを使用します。たとえば、ID が 29502553 の Tablet を確認する場合は次のとおりです。
SHOW TABLET 29502553;
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| DbName | TableName | PartitionName | IndexName | DbId | TableId | PartitionId | IndexId | IsSync | DetailCmd |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| default_cluster:test | test | test | test | 29502391 | 29502428 | 29502427 | 29502428 | true | SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553'; |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
出力には、その Tablet が属するデータベース、テーブル、パーティション、ロールアップテーブルなどの情報が表示されます。DetailCmd 列のコマンドをコピーして実行します。
SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553';
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State | IsBad | VersionCount | PathHash | MetaUrl | CompactionStatus |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| 43734060 | 10004 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | -8566523878520798656 | url | url |
| 29502555 | 10002 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1885826196444191611 | url | url |
| 39279319 | 10007 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1656508631294397870 | url | url |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
出力には、対象の Tablet のすべてのレプリカの状態が表示されます。内容は SHOW TABLETS FROM tbl1; と同じですが、特定の Tablet の全レプリカの状態を明確に確認できます。
レプリカのスケジューリングタスク
次のコマンドで、待機中、実行中、完了済み のスケジューリングタスクを個別に確認できます。
| 状態 | コマンド |
|---|---|
| 待機中 | SHOW PROC '/cluster_balance/pending_tablets'; |
| 実行中 | SHOW PROC '/cluster_balance/running_tablets'; |
| 完了済み | SHOW PROC '/cluster_balance/history_tablets'; |
出力例（pending_tablets）:
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| TabletId | Type | Status | State | OrigPrio | DynmPrio | SrcBe | SrcPath | DestBe | DestPath | Timeout | Create | LstSched | LstVisit | Finished | Rate | FailedSched | FailedRunning | LstAdjPrio | VisibleVer | VisibleVerHash | CmtVer | CmtVerHash | ErrMsg |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
| 4203036 | REPAIR | REPLICA_MISSING | PENDING | HIGH | LOW | -1 | -1 | -1 | -1 | 0 | 2019-02-21 15:00:20 | 2019-02-24 11:18:41 | 2019-02-24 11:18:41 | N/A | N/A | 2 | 0 | 2019-02-21 15:00:43 | 1 | 0 | 2 | 0 | unable to find source replica |
+----------+--------+-----------------+---------+----------+----------+-------+---------+--------+----------+---------+---------------------+---------------------+---------------------+----------+------+-------------+---------------+---------------------+------------+---------------------+--------+---------------------+-------------------------------+
各列の意味は次のとおりです。
| 列 | 意味 |
|---|---|
| TabletId | スケジューリングを待つ Tablet の ID。各スケジューリングタスクが対象とする Tablet は一つだけです。 |
| Type | タスクの種類: REPAIR または BALANCE。 |
| Status | Tablet の現在の状態。たとえば REPLICA_MISSING。 |
| State | スケジューリングタスクの状態: PENDING / RUNNING / FINISHED / CANCELLED / TIMEOUT / UNEXPECTED。 |
| OrigPrio | 初期優先度。 |
| DynmPrio | 動的調整後の現在の優先度。 |
| SrcBe | コピー元 BE ノードの ID。 |
| SrcPath | コピー元 BE ノードのパスのハッシュ値。 |
| DestBe | 宛先 BE ノードの ID。 |
| DestPath | 宛先 BE ノードのパスのハッシュ値。 |
| Timeout | タスクが正常にスケジュールされた後のタイムアウト（秒）。 |
| Create | タスクが作成された時刻。 |
| LstSched | タスクが最後にスケジュールされた時刻。 |
| LstVisit | タスクが最後に処理された時刻。ここでの「処理」には、スケジューリングやタスク実行結果の報告など、タスクに関するあらゆる処理が含まれます。 |
| Finished | タスクが完了した時刻。 |
| Rate | クローンタスクのデータコピー速度。 |
| FailedSched | タスクのスケジューリングに失敗した回数。 |
| FailedRunning | タスクの実行に失敗した回数。 |
| LstAdjPrio | 優先度を最後に調整した時刻。 |
| CmtVer / CmtVerHash / VisibleVer / VisibleVerHash | クローンタスクの実行に使用されるバージョン情報。 |
| ErrMsg | タスクのスケジューリングと実行中に発生したエラーメッセージ。 |
running_tablets の各列の意味は pending_tablets と同じです。
history_tablets はデフォルトで直近の完了済みタスク 1000 件のみを保持します。各列の意味は上記と同じです。
StateがFINISHEDの場合、タスクは正常に完了しています。- その他の値の場合は、
ErrMsg列のエラーメッセージを基に診断できます。
クラスター負荷とスケジューリングリソースの確認
クラスター負荷
次のコマンドで、クラスターの現在の負荷を確認できます。
SHOW PROC '/cluster_balance/cluster_load_stat/location_default';
最初に、ストレージメディア別の内訳が表示されます。
+---------------+
| StorageMedium |
+---------------+
| HDD |
| SSD |
+---------------+
ストレージメディアの階層をさらにたどると、そのメディアを持つ BE ノードのバランス状態を確認できます。
SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD';
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| BeId | Cluster | Available | UsedCapacity | Capacity | UsedPercent | ReplicaNum | CapCoeff | ReplCoeff | Score | Class |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
| 10003 | default_cluster | true | 3477875259079 | 19377459077121 | 17.948 | 493477 | 0.5 | 0.5 | 0.9284678149967587 | MID |
| 10002 | default_cluster | true | 3607326225443 | 19377459077121 | 18.616 | 496928 | 0.5 | 0.5 | 0.948660871419998 | MID |
| 10005 | default_cluster | true | 3523518578241 | 19377459077121 | 18.184 | 545331 | 0.5 | 0.5 | 0.9843539990641831 | MID |
| 10001 | default_cluster | true | 3535547090016 | 19377459077121 | 18.246 | 558067 | 0.5 | 0.5 | 0.9981869446537612 | MID |
| 10006 | default_cluster | true | 3636050364835 | 19377459077121 | 18.764 | 547543 | 0.5 | 0.5 | 1.0011489897614072 | MID |
| 10004 | default_cluster | true | 3506558163744 | 15501967261697 | 22.620 | 468957 | 0.5 | 0.5 | 1.0228319835582569 | MID |
| 10007 | default_cluster | true | 4036460478905 | 19377459077121 | 20.831 | 551645 | 0.5 | 0.5 | 1.057279369420761 | MID |
| 10000 | default_cluster | true | 4369719923760 | 19377459077121 | 22.551 | 547175 | 0.5 | 0.5 | 1.0964036415787461 | MID |
+----------+-----------------+-----------+---------------+----------------+-------------+------------+----------+-----------+--------------------+-------+
各列の意味は次のとおりです。
| 列 | 意味 |
|---|---|
| Available | true の場合、BE のハートビートが正常で、デコミッション中ではありません。 |
| UsedCapacity | BE が使用しているディスク容量（バイト）。 |
| Capacity | BE のディスク総容量（バイト）。 |
| UsedPercent | BE のディスク使用率（パーセント）。 |
| ReplicaNum | BE 上のレプリカ数。 |
| CapCoeff / ReplCoeff | ディスク容量とレプリカ数に対する重み係数。 |
| Score | 負荷スコア。値が高いほど負荷が高くなります。 |
| Class | 負荷レベルによる分類: LOW / MID / HIGH。バランシングでは高負荷ノードから低負荷ノードへレプリカを移行します。 |
さらに階層をたどると、特定の BE 上の各パスの使用状況を確認できます。たとえば、ID が 10001 の BE を表示するには次のようにします。
SHOW PROC '/cluster_balance/cluster_load_stat/location_default/HDD/10001';
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| RootPath | DataUsedCapacity | AvailCapacity | TotalCapacity | UsedPct | State | PathHash |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
| /home/disk4/palo | 498.757 GB | 3.033 TB | 3.525 TB | 13.94 % | ONLINE | 4883406271918338267 |
| /home/disk3/palo | 704.200 GB | 2.832 TB | 3.525 TB | 19.65 % | ONLINE | -5467083960906519443 |
| /home/disk1/palo | 512.833 GB | 3.007 TB | 3.525 TB | 14.69 % | ONLINE | -7733211489989964053 |
| /home/disk2/palo | 881.955 GB | 2.656 TB | 3.525 TB | 24.65 % | ONLINE | 4870995507205544622 |
| /home/disk5/palo | 694.992 GB | 2.842 TB | 3.525 TB | 19.36 % | ONLINE | 1916696897889786739 |
+------------------+------------------+---------------+---------------+---------+--------+----------------------+
出力には、指定した BE 上の各データパスのディスク使用状況が表示されます。
スケジューリングリソース
次のコマンドで各ノードのスロット使用状況を確認できます。
SHOW PROC '/cluster_balance/working_slots';
+----------+----------------------+------------+------------+-------------+----------------------+
| BeId | PathHash | AvailSlots | TotalSlots | BalanceSlot | AvgRate |
+----------+----------------------+------------+------------+-------------+----------------------+
| 10000 | 8110346074333016794 | 2 | 2 | 2 | 2.459007474009069E7 |
| 10000 | -5617618290584731137 | 2 | 2 | 2 | 2.4730105014001578E7 |
| 10001 | 4883406271918338267 | 2 | 2 | 2 | 1.6711402709780257E7 |
| 10001 | -5467083960906519443 | 2 | 2 | 2 | 2.7540126380326536E7 |
| 10002 | 9137404661108133814 | 2 | 2 | 2 | 2.417217089806745E7 |
| 10002 | 1885826196444191611 | 2 | 2 | 2 | 1.6327378456676323E7 |
+----------+----------------------+------------+------------+-------------+----------------------+
スロットの使用状況はデータパス単位で表示されます。AvgRate は、そのパスで実行されたクローンタスクの過去の統計に基づくコピー速度で、単位はバイト/秒です。
優先修復の確認
次のコマンドで、ADMIN REPAIR TABLE により優先修復が設定されたテーブルまたはパーティションを確認できます。
SHOW PROC '/cluster_balance/priority_repair';
RemainingTimeMs は、優先修復の対象が優先修復キューから自動的に削除されるまでの残り時間を示します。これにより、優先修復が失敗し続けてリソースを占有することを防ぎます。
スケジューラー統計の確認
Doris は動作中に TabletChecker と TabletScheduler の統計情報を収集します。次のコマンドで確認できます。
SHOW PROC '/cluster_balance/sched_stat';
+---------------------------------------------------+-------------+
| Item | Value |
+---------------------------------------------------+-------------+
| num of tablet check round | 12041 |
| cost of tablet check(ms) | 7162342 |
| num of tablet checked in tablet checker | 18793506362 |
| num of unhealthy tablet checked in tablet checker | 7043900 |
| num of tablet being added to tablet scheduler | 1153 |
| num of tablet schedule round | 49538 |
| cost of tablet schedule(ms) | 49822 |
| num of tablet being scheduled | 4356200 |
| num of tablet being scheduled succeeded | 320 |
| num of tablet being scheduled failed | 4355594 |
| num of tablet being scheduled discard | 286 |
| num of tablet priority upgraded | 0 |
| num of tablet priority downgraded | 1096 |
| num of clone task | 230 |
| num of clone task succeeded | 228 |
| num of clone task failed | 2 |
| num of clone task timeout | 2 |
| num of replica missing error | 4354857 |
| num of replica version missing error | 967 |
| num of replica relocating | 0 |
| num of replica redundant error | 90 |
| num of replica missing in cluster error | 0 |
| num of balance scheduled | 0 |
+---------------------------------------------------+-------------+
各行の意味は次のとおりです。
| 指標 | 意味 |
|---|---|
| num of tablet check round | Tablet Checker が実行された回数。 |
| cost of tablet check(ms) | Tablet Checker の累積実行時間。 |
| num of tablet checked in tablet checker | Tablet Checker が確認した Tablet の数。 |
| num of unhealthy tablet checked in tablet checker | Tablet Checker が確認した異常な Tablet の数。 |
| num of tablet being added to tablet scheduler | Tablet Scheduler に送られた Tablet の数。 |
| num of tablet schedule round | Tablet Scheduler が実行された回数。 |
| cost of tablet schedule(ms) | Tablet Scheduler の累積実行時間。 |
| num of tablet being scheduled | スケジュールされた Tablet の総数。 |
| num of tablet being scheduled succeeded | 正常にスケジュールされた Tablet の総数。 |
| num of tablet being scheduled failed | スケジューリングに失敗した Tablet の総数。 |
| num of tablet being scheduled discard | スケジューリングに失敗して破棄された Tablet の総数。 |
| num of tablet priority upgraded | 優先度が引き上げられた回数。 |
| num of tablet priority downgraded | 優先度が引き下げられた回数。 |
| num of clone task | 生成されたクローンタスクの数。 |
| num of clone task succeeded | 成功したクローンタスクの数。 |
| num of clone task failed | 失敗したクローンタスクの数。 |
| num of clone task timeout | タイムアウトしたクローンタスクの数。 |
| num of replica missing error | レプリカ不足の状態であることが確認された Tablet の数。 |
| num of replica version missing error | バージョン欠落の状態であることが確認された Tablet の数（num of replica relocating と num of replica missing in cluster error を含む）。 |
| num of replica relocating | レプリカ移動中の状態であることが確認された Tablet の数。 |
| num of replica redundant error | レプリカが冗長な状態であることが確認された Tablet の数。 |
| num of replica missing in cluster error | 対応するクラスター内にレプリカがない状態であることが確認された Tablet の数。 |
| num of balance scheduled | バランシングがスケジュールされた回数。 |
注: 上記の状態値はすべて、過去からの累積値です。FE ログにもこれらの統計情報が定期的に出力されます。ログ内の括弧付きの値は、前回の出力からの各統計値の変化を示します。
関連する設定
調整可能なパラメーター（FE）
以下の調整可能なパラメーターはすべて fe.conf で設定できます。
| パラメーター | 説明 | デフォルト | 重要度 |
|---|---|---|---|
| use_new_tablet_scheduler | 新しいレプリカスケジューリング方式を有効にするかどうか。このドキュメントで説明している方式です。 | true | 高 |
| tablet_repair_delay_factor_second | 日常的な再起動やアップグレードなどの際に不要なレプリカ修復タスクが大量に発生しないよう、優先度に応じて修復開始を遅らせます。基準係数に対し、HIGH は base coefficient * 1、NORMAL は base coefficient * 2、LOW は base coefficient * 3 の時間だけ遅延します。優先度が低いほど待機時間が長くなります。レプリカを迅速に修復する必要がある場合は、この値を下げます。 | 60 秒 | 高 |
| schedule_slot_num_per_path | レプリカ修復のために各ディスクに割り当てられるデフォルトのスロット数です。ディスクごとに同時実行できるレプリカ修復タスクの数を表します。値を大きくすると修復は速くなりますが、IO への影響も大きくなります。 | 2 | 高 |
| balance_load_score_threshold | クラスターのバランシングのしきい値です。BE ノードの負荷スコアと平均負荷スコアの差がこの値を超えなければ、クラスターは均衡しているとみなされます。負荷をより均等にしたい場合は、この値を下げます。 | 0.1（10%） | 中 |
| storage_high_watermark_usage_percent | ディスク使用率の上限です。超過したディスクは、バランシングの宛先として使用されなくなります。 | 0.85 | 中 |
| storage_min_left_capacity_bytes | ディスクの残容量の下限です。残容量がこの値を下回ると、そのディスクはバランシングの宛先として使用されなくなります。 | 2097152000（2 GB） | 中 |
| disable_balance | バランシング機能を無効にするかどうかを制御します。バランシング中は一部の操作（ALTER TABLE など）が禁止され、バランシングが長時間続く場合があります。禁止されている操作をできるだけ早く実行する必要がある場合は true に設定します。 | false | 中 |
調整可能なパラメーター（BE）
以下の調整可能なパラメーターはすべて be.conf で設定できます。
| パラメーター | 説明 | デフォルト | 重要度 |
|---|---|---|---|
| clone_worker_count | レプリカのバランシング速度に影響します。ディスク負荷が低い場合、この値を調整してバランシングを高速化できます。 | 3 | 中 |
調整できないパラメーター
以下のパラメーターは現時点では変更できません。参考情報として記載します。
| 項目 | 説明 |
|---|---|
| TabletChecker のスケジューリング間隔 | TabletChecker は 20 秒ごとに確認とスケジューリングを行います。 |
| TabletScheduler のスケジューリング間隔 | TabletScheduler は 5 秒ごとにスケジューリングを行います。 |
| TabletScheduler が一度にスケジュールするタスク数 | TabletScheduler は各ラウンドで最大 50 個の Tablet をスケジュールします。 |
| TabletScheduler の待機中および実行中タスクの最大数 | 待機中と実行中のタスクは最大 2000 件です。これを超えると、TabletChecker は TabletScheduler 向けの新しいスケジューリングタスクを生成しません。 |
| TabletScheduler のバランシングタスクの最大数 | バランシングタスクは最大 500 件です。これを超えると、新しいバランシングタスクは生成されません。 |
| バランシングタスク用のディスクあたりのスロット数 | 各ディスクのバランシングタスク用スロットは 2 つです。このスロットはレプリカ修復用スロットとは独立しています。 |
| クラスターのバランス情報の更新間隔 | TabletScheduler はクラスターの負荷スコアを 20 秒ごとに再計算します。 |
| クローンタスクのタイムアウトの最小値と最大値 | クローンタスクのタイムアウトは 3 分から 2 時間です。具体的な値は (tablet size) / (5 MB/s) で計算されます。クローンタスクは実行に 3 回失敗すると終了します。 |
| 優先度の動的調整戦略 | 優先度の調整間隔は最短で 5 分です。Tablet はスケジューリングに 5 回失敗すると優先度が下がり、30 分間スケジュールされないと優先度が上がります。 |
関連する問題
- デフォルトのレプリカ修復・バランシング戦略では、ネットワーク帯域を使い切る場合があります（ギガビットのネットワークカードを使用し、BE あたりのディスク数が多い場合によく発生します）。その場合は、パラメーターを調整して、同時に実行するバランシングタスクと修復タスクの数を減らす必要があります。
- 現在の Colocate テーブル向けのレプリカバランシング戦略では、同じ Tablet のレプリカが同一ホスト上の複数の BE に配置されないことを保証できません。一方、Colocate テーブル向けの修復戦略はこの配置の問題を検出して修正します。修正後、バランシング戦略がレプリカを再び不均衡とみなして再配置する場合があり、この二つの状態が繰り返されて Colocate Group が安定しなくなります。この問題が起きる可能性を減らすため、Colocate 属性を使用する場合はクラスター構成をできるだけ均一にしてください。
ベストプラクティス
クラスターのレプリカ修復とバランシングの進行状況を制御・管理する
通常、Doris はデフォルトのパラメーター設定でレプリカ修復とクラスターのバランシングを自動的に行えます。ただし、特定のテーブルやパーティションの修復を優先する、クラスター負荷を下げるためにバランシングを無効にする、非 Colocation テーブルのデータ修復を優先するなど、目的に応じて手動でパラメーターを調整する必要がある場合があります。このセクションでは、パラメーターを変更して修復とバランシングの進行を制御・管理する方法を説明します。
1. 破損したレプリカを削除する
Doris が破損したレプリカを検出できず、そのレプリカでクエリやインポートのエラーが頻繁に発生する場合があります。その場合は、破損したレプリカを手動で削除する必要があります。この方法は、バージョン数が多すぎて -235 エラーを起こすレプリカや、ファイルが破損したレプリカなどの削除に適用できます。
手順:
-
対象のレプリカに対応する Tablet ID を調べます。ここでは 10001 とします。
-
show tablet 10001;を実行し、その結果に表示されるshow proc文を実行して、Tablet の各レプリカの詳細を確認します。 -
削除対象のレプリカが配置されている Backend ID を 20001 とします。次の文を実行して、レプリカを
badとマークします。ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "10001", "backend_id" = "20001", "status" = "bad"); -
show proc文を再度実行し、対象レプリカのIsBad列がtrueになっていることを確認します。
bad とマークされたレプリカは、インポートやクエリに参加しなくなります。同時に、レプリカ修復処理によって新しいレプリカが自動的に補充されます。
2. テーブルまたはパーティションの修復を優先する
help admin repair table; を実行してヘルプを確認します。このコマンドは、指定したテーブルまたはパーティションの Tablet の修復を優先しようとします。
3. バランシングタスクを停止する
バランシングタスクはネットワーク帯域と IO リソースを消費します。新しいバランシングタスクが生成されないようにするには、次を実行します。
ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");
4. すべてのレプリカスケジューリングタスクを停止する
レプリカスケジューリングタスクには、バランシングタスクと修復タスクが含まれます。これらはネットワーク帯域と IO リソースを消費します。次のコマンドを実行すると、Colocation テーブルと通常のテーブルの両方で、すべてのレプリカスケジューリングタスクが停止します（実行中のタスクを除く）。
ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");
5. Colocation テーブルのすべてのレプリカスケジューリングタスクを停止する
Colocation テーブルと通常のテーブルのレプリカスケジューリングは独立して動作します。クラスターのリソースを通常のテーブルの修復に使えるよう、Colocation テーブルのバランシングと修復を先に停止したい場合があります。
ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");
6. より慎重な戦略でレプリカを修復する
Doris はレプリカの欠落や BE の停止などを検出すると、レプリカを自動的に修復します。BE の短時間の停止など、一時的な問題によるエラーを減らすため、これらのタスクの開始を遅らせます。
-
tablet_repair_delay_factor_secondパラメーター: デフォルトは 60 秒です。修復タスクの優先度に応じて、60 秒、120 秒、または 180 秒の遅延後にタスクが開始されます。次のコマンドは遅延を延長し、異常が長引いても不要な修復タスクが開始されないようにします。ADMIN SET FRONTEND CONFIG ("tablet_repair_delay_factor_second" = "120");
7. より慎重な戦略で Colocation Group の再配置を開始する
Colocation Group の再配置では、多数の Tablet が移行される場合があります。colocate_group_relocate_delay_second は再配置を開始するまでの遅延を制御し、デフォルトは 1800 秒です。BE ノードが長時間オフラインになる可能性がある場合は、不要な再配置を避けるため、この値を増やすことを検討してください。
ADMIN SET FRONTEND CONFIG ("colocate_group_relocate_delay_second" = "3600");
8. レプリカのバランシングを高速化する
Doris のレプリカバランシングでは、まず正常なレプリカを追加し、その後に古いレプリカを削除して移行します。バランシングがインポートタスクに影響しないよう、古いレプリカを削除する際には、そのレプリカ上ですでに開始されたインポートタスクの完了を待ちます。ただし、この待機によってバランシングの実行が遅くなります。次のパラメーターを設定すると、待機せずに古いレプリカを直接削除します。
ADMIN SET FRONTEND CONFIG ("enable_force_drop_redundant_replica" = "true");
この操作によってバランシング中に一部のインポートタスクが失敗し、再試行が必要になる場合がありますが、バランシングは大幅に速くなります。
クラスターを迅速に復旧するための推奨手順
クラスターを速やかに正常な状態へ戻すには、次の方法を検討してください。
- 優先度の高いタスクでエラーを起こしている Tablet を特定し、問題のあるレプリカを
badとマークします。 ADMIN REPAIR文を使用して、特定のテーブルの修復を優先します。- クラスターのリソース消費を避けるためレプリカのバランシングを停止し、クラスターの復旧後に再度有効にします。
- BE の頻繁な停止によって修復タスクが一斉に発生する場合は、より慎重な戦略で修復タスクを開始します。
- 必要に応じて Colocation テーブルのスケジューリングタスクを無効にし、他の優先度の高いデータの修復にクラスターリソースを集中させます。
FAQ
Q: SHOW PROC '/cluster_health/tablet_health' コマンドでエラーが出る、またはデータが不完全な場合はどうすればよいですか？
このコマンドを実行するには、Master FE に直接接続する必要があります。現在接続している FE が Master かどうかを確認してください。
Q: レプリカが長時間 REPLICA_MISSING のまま修復されない場合、どう調査すればよいですか？
ErrMsg の内容を SHOW PROC '/cluster_balance/pending_tablets' で確認してください。よくある原因には、適切なコピー元や宛先が見つからない、ディスク容量が不足している、ノードがデコミッション中であることなどがあります。
Q: 修復タスクのスケジューリング失敗が多い場合はどうすればよいですか？
SHOW PROC '/cluster_balance/sched_stat' で失敗の統計を確認してください。schedule_slot_num_per_hdd_path または schedule_slot_num_per_ssd_path を増やすことを検討するか、ディスク容量不足や利用できないノードなどを調べてください。
Q: レプリカのバランシングでネットワーク帯域を使い切る場合はどうすればよいですか？
同時に実行するバランシングタスクと修復タスクの数を減らすか、一時的に ADMIN SET FRONTEND CONFIG ("disable_balance" = "true"); を実行してください。
Q: Colocate Group が長時間安定しない場合はどうすればよいですか？
クラスター構成をできるだけ均一にし、colocate_group_relocate_delay_second を増やして不要な再配置を減らしてください。
Q: BE の停止直後に多数のレプリカが修復され、負荷が急変する場合はどうすればよいですか？
tablet_repair_delay_factor_second を増やして、異常が続いても修復を開始しない猶予期間を延ばしてください。
Q: bad レプリカを削除してもエラーが続く場合はどうすればよいですか？
SHOW PROC '/dbs/.../<tablet_id>' ですべてのレプリカが補充されたことを確認し、クローンタスクの完了を待ってください。