データレプリカ管理

バージョン0.9.0以降、Dorisは最適化されたレプリカ管理戦略を導入し、より豊富なレプリカステータス表示ツールをサポートしています。本ドキュメントでは、Dorisデータレプリカのバランシング、修復スケジューリング戦略、およびレプリカ管理の運用保守方法に焦点を当てています。ユーザーがクラスター内のレプリカステータスをより簡単に習得し管理できるよう支援します。

Colocation属性を持つテーブルのコピーの修復とバランシングについてはこちらを参照してください

用語解説

1. Tablet: Dorisテーブルの論理的な断片化であり、テーブルは複数の断片を持ちます。
2. Replica: スライスされたコピーで、デフォルトではスライスの3つのコピーがあります。
3. Healthy Replica: Backendで存続し、完全なバージョンを持つ健全なコピー。
4. Tablet Checker (TC): すべてのTabletを定期的にスキャンし、これらのTabletのステータスをチェックし、結果に基づいてTablet Schedulerに送信するかどうかを決定する常駐バックグラウンドスレッド。
5. Tablet Scheduler (TS): Tablet Checkerによって送信された修復が必要なTabletを処理する常駐バックグラウンドスレッド。同時に、クラスターレプリカバランシングも実行されます。
6. Tablet SchedCtx (TSC): tabletのカプセル化です。TCがtabletを選択する際、それをTSCとしてカプセル化してTSに送信します。
7. Storage Medium: ストレージメディア。Dorisはパーティション粒度で異なるストレージメディアの指定をサポートしており、SSDとHDDが含まれます。レプリカスケジューリング戦略も異なるストレージメディアに対してスケジュールされます。

              +--------+              +-----------+
              |  Meta  |              |  Backends |
              +---^----+              +------^----+
                  | |                        | 3. Send clone tasks
 1. Check tablets | |                        |
           +--------v------+        +-----------------+
           | TabletChecker +--------> TabletScheduler |
           +---------------+        +-----------------+
                   2. Waiting to be scheduled

上記の図は簡略化されたワークフローです。

複製状態

特定の状況により、Tabletの複数のコピーが状態の不整合を引き起こす可能性があります。Dorisは、クラスタができるだけ早く誤った状態から回復できるように、これらの状態の不整合なコピーを自動的に修復しようと試みます。

Replicaの健全性状態は以下の通りです：

1. BAD

   つまり、コピーが破損しています。これには、ディスク障害、BUG等によって引き起こされるコピーの回復不可能な破損状態が含まれますが、これに限定されません。

2. VERSION_MISSING

   バージョンが欠落しています。Dorisにおける各インポートバッチは、データバージョンに対応します。データのコピーは、連続するいくつかのバージョンで構成されます。しかし、インポートエラー、遅延などの理由により、一部のコピーのデータバージョンが不完全になる可能性があります。

3. HEALTHY

   健全なコピー。つまり、正常なデータのコピーで、そのコピーが配置されているBEノードが正常な状態にあります（ハートビートが正常で、オフラインプロセスにない）。

Tabletの健全性状態は、そのすべてのコピーの状態によって決定されます。以下のカテゴリがあります：

1. REPLICA_MISSING

   コピーが欠落しています。つまり、生存しているコピーの数が期待されるコピー数よりも少ない状態です。

2. VERSION_INCOMPLETE

   生存しているコピーの数は期待されるコピー数以上ですが、健全なコピーの数が期待されるコピー数未満です。

3. REPLICA_RELOCATING

   replication numバージョンの完全な数の生存コピーを持っていますが、一部のコピーが配置されているBEノードが利用不可能な状態（decommissionなど）にあります。

4. REPLICA_MISSING_IN_CLUSTER

   マルチクラスタを使用する場合、健全なレプリカの数は期待されるレプリカ数以上ですが、対応するクラスタ内のレプリカ数が期待されるレプリカ数未満です。

5. REDUNDANT

   重複した冗長性。健全なレプリカが対応するクラスタにありますが、レプリカ数が期待される数よりも大きい状態です。または利用不可能な予備コピーが存在します。

6. FORCE_REDUNDANT

   これは特殊な状態です。既存のレプリカ数が利用可能なノード数以上で、利用可能なノード数が期待されるレプリカ数以上で、生存しているレプリカ数が期待されるレプリカ数未満の場合にのみ発生します。この場合、新しいコピーを作成するための利用可能なノードを確保するため、まずコピーを削除する必要があります。

7. COLOCATE_MISMATCH

   Collocation属性を持つテーブルの断片化状態。断片化されたコピーの分散がColocation Groupの指定された分散と一致しないことを表します。

8. COLOCATE_REDUNDANT

   Collocation属性を持つテーブルの断片化状態。Colocationテーブルの断片化されたコピーの冗長性を表します。

9. HEALTHY

   健全な断片化、つまり条件[1-5]が満たされない状態です。

レプリカ修復

常駐バックグラウンドプロセスとして、Tablet Checkerは定期的にすべての断片の状態をチェックします。不健全な断片化に対しては、スケジューリングと修復のためにTablet Schedulerに送信されます。修復の実際の操作は、BE上のclone taskによって実行されます。FEはこれらのclone taskを生成することのみを担当します。

注1：レプリカ修復の主なアイデアは、まず断片化されたレプリカを作成または完成させることで、断片化されたレプリカの数を望ましい値に到達させることです。その後、冗長なコピーを削除します。

注2：clone taskは、指定されたリモートエンドから指定された宛先へ指定されたデータをコピーするプロセスを完了することです。

異なる状態に対して、我々は異なる修復方法を採用します：

1. REPLICA_MISSING/REPLICA_RELOCATING

   低負荷で利用可能なBEノードを宛先として選択します。健全なコピーをソースとして選択します。Clone taskはソースから宛先へ完全なコピーをコピーします。レプリカ補完の場合、ストレージメディアに関係なく、利用可能なBEノードを直接選択します。

2. VERSION_INCOMPLETE

   比較的完全なコピーを宛先として選択します。健全なコピーをソースとして選択します。clone taskは、欠落しているバージョンをソースから宛先へコピーしようと試みます。

3. REPLICA_MISSING_IN_CLUSTER

   この状態の処理方法はREPLICA_MISSINGと同じです。

4. REDUNDANT

   通常、修復後には断片化に冗長なコピーが存在します。冗長なコピーを選択してそれを削除します。冗長なコピーの選択は以下の優先順位に従います：

   1. コピーが配置されているBEがオフラインになっている
   2. コピーが破損している
   3. コピーがBEで失われているかオフラインになっている
   4. レプリカがCLONE状態にある（これはclone task実行中の中間状態）
   5. コピーにバージョンの欠落がある
   6. コピーが配置されているクラスタが正しくない
   7. レプリカが配置されているBEノードの負荷が高い

5. FORCE_REDUNDANT

   REDUNDANTとは異なり、この時点でTabletにはコピーが欠落しているため、新しいコピーを作成するための追加の利用可能なノードがありません。そのため、この時点では、新しいコピーを作成するための利用可能なノードを解放するために、コピーを削除する必要があります。 コピーを削除する順序はREDUNDANTと同じです。

6. COLOCATE_MISMATCH

   レプリカ補完の宛先ノードとして、Colocation Groupで指定されたレプリカ分散BEノードのうち1つを選択します。

7. COLOCATE_REDUNDANT

   非Colocation Groupで指定されたコピーによって分散されるBEノード上のコピーを削除します。

   Dorisは、レプリカノードを選択する際に、同じTabletのコピーを同じホストの異なるBEに配置しません。これにより、同じホスト上のすべてのBEが無効化されても、すべてのコピーが失われないことが保証されます。

スケジューリング優先度

Tablet Schedulerでスケジュールを待機している断片は、状態に応じて異なる優先度が与えられます。高優先度の断片が最初にスケジュールされます。現在、いくつかの優先度があります。

1. VERY_HIGH

   • REDUNDANT。重複する冗長性を持つスライスに対して、我々はそれらを優先します。論理的には、重複する冗長性は最も緊急度が低いですが、処理が最も速く、リソース（ディスク領域など）を迅速に解放できるため、我々はそれを優先します。
   • FORCE_REDUNDANT。同上。

2. HIGH

   • REPLICA_MISSINGで、ほとんどのコピーが欠落している（例：3コピーのうち2コピーが欠落）
   • VERSION_INCOMPLETEで、ほとんどのコピーが欠落している
   • COLOCATE_MISMATCH Collocationテーブルに関連する断片化ができるだけ早く修復されることを期待します。
   • COLOCATE_REDUNDANT

3. NORMAL

   • REPLICA_MISSINGだが、ほとんどが生存している（例：3コピーのうち1つが失われた）
   • VERSION_INCOMPLETEだが、ほとんどのコピーが完全
   • REPLICA_RELOCATINGで、ほとんどのレプリカに対してrelocateが必要（例：3レプリカのうち2レプリカ）

4. LOW

   • REPLICA_MISSING_IN_CLUSTER
   • REPLICA_RELOCATINGで、ほとんどのコピーが安定

手動優先度

システムは自動的にスケジューリング優先度を決定します。しかし、ユーザが一部のテーブルやパーティションの断片化をより速く修復したい場合があります。そのため、ユーザが特定のテーブルやパーティションのスライスを最初に修復するよう指定できるコマンドを提供しています：

ADMIN REPAIR TABLE tbl [PARTITION (p1, p2, ...)];

このコマンドは、TabletをスキャンするときにTCが最初に修復する必要がある問題のあるテーブルやパーティションにVERY HIGH優先度を与えるよう指示します。

注：このコマンドは単なるヒントであり、修復の成功を保証するものではなく、優先度はTSのスケジューリングと共に変化します。また、Master FEが切り替わったり再起動したりすると、この情報は失われます。

優先度は以下のコマンドでキャンセルできます：

ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];

優先度スケジューリング

優先度により、重大に破損した断片を最初に修復でき、システムの可用性が向上します。しかし、高優先度の修復タスクが常に失敗する場合、低優先度のタスクは決してスケジュールされません。そのため、タスクの実行状況に応じてタスクの優先度を動的に調整し、すべてのタスクにスケジュールされる機会があることを保証します。

• スケジューリングが5回連続で失敗した場合（例：リソースを取得できない、適切なソースや宛先が見つからないなど）、優先度が下げられます。
• 30分間スケジュールされなかった場合、優先度が上げられます。
• 同じtabletタスクの優先度調整は、最低5分間の間隔があります。

同時に、初期優先度の重みを保証するため、初期優先度がVERY HIGHの場合、最低でもNORMALまで下げられると規定しています。初期優先度がLOWの場合、最高でもHIGHまで上げられます。ここでの優先度調整は、ユーザによって手動で設定された優先度も調整します。

レプリカバランス

Dorisはクラスタ内でレプリカを自動的にバランスします。現在、BeLoadとPartitionの2つのリバランス戦略をサポートしています。BeLoadリバランスは、各BEのディスク使用量とレプリカ数を考慮します。Partitionリバランスは各パーティションのレプリカ数のみを対象とし、これはホットスポットの回避に役立ちます。高い読み書きパフォーマンスが必要な場合は、これが必要かもしれません。Partitionリバランスはディスク使用量を考慮しないため、Partitionリバランスを使用する際はより注意を払ってください。戦略選択設定は実行時に変更可能ではありません。

BeLoad

バランシングの主なアイデアは、低負荷ノード上で一部の断片のレプリカを作成し、その後高負荷ノード上でこれらの断片のレプリカを削除することです。同時に、異なるストレージメディアの存在により、同じクラスタ内の異なるBEノードに1つまたは2つのストレージメディアが存在する場合と存在しない場合があります。我々は、等化後にストレージメディアAの断片をできるだけストレージメディアAに保存することを要求します。そのため、ストレージメディアに応じてクラスタのBEノードを分割します。その後、ストレージメディアの異なるBEノードセットに対して負荷分散スケジューリングを実行します。

同様に、レプリカバランシングは、同じテーブルのコピーが同じホストのBE上に配置されないことを保証します。

BEノード負荷

我々は、クラスタ内の各backendの負荷分散を表すためにCluster LoadStatistics（CLS）を使用します。Tablet Schedulerは、この統計に基づいてクラスタ平衡をトリガーします。現在、ディスク使用量とコピー数を使用して各BEの負荷Scoreを計算し、BEの負荷スコアとしています。スコアが高いほど、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%の間の場合、重み係数はスムーズに増加します。式は以下の通りです：

capacityCoefficient = 2 * Disk Utilization - 0.5

重み係数により、ディスク使用率が高すぎる場合、backend負荷スコアがより高くなり、BEの負荷ができるだけ早く軽減されることが保証されます。

Tablet SchedulerはCLSを20秒ごとに更新します。

Partition

partition rebalancingの主なアイデアは、パーティションのskewを減らすことです。パーティションのskewは、すべてのBE上でのパーティションの最大レプリカ数と最小レプリカ数の差として定義されます。

そのため、我々はレプリカ数のみを考慮し、レプリカサイズ（ディスク使用量）は考慮しません。 移動を少なくするため、クラスタとパーティションの2次元であるTwoDimensionalGreedyAlgoを使用します。最大skewパーティションをリバランスしたい場合、クラスタのskewを減らす移動を優先します。

Skew情報

skew情報はClusterBalanceInfoによって表されます。partitionInfoBySkewは、キーがパーティションのskewであるmultimapであるため、最大skewパーティションを簡単に取得できます。beByTotalReplicaCountは、キーがbackendの総レプリカ数であるmultimapです。

ClusterBalanceInfoはCLS内にあり、20秒ごとに更新されます。

複数の最大skewパーティションを取得する場合、移動を計算するためにランダムに1つのパーティションを選択します。

平衡戦略

Tablet SchedulerはLoad Balancerを使用して、各スケジューリングラウンドでバランス候補断片として一定数の健全な断片を選択します。次のスケジューリングでは、これらの候補断片に基づいてバランススケジューリングが試行されます。

リソース制御

レプリカ修復とバランシングの両方が、BE間のレプリカコピーによって実行されます。同じBEが同時に多くのタスクを実行すると、多くのIO圧力をもたらします。そのため、Dorisはスケジューリング中に各ノードで実行できるタスク数を制御します。最小のリソース制御単位はディスク（つまり、be.confで指定されたデータパス）です。デフォルトでは、レプリカ修復用にディスクごとに2つのスロットを設定します。clone taskは、ソースで1つのスロット、宛先で1つのスロットを占有します。スロット数がゼロの場合、このディスクにはこれ以上のタスクが割り当てられません。スロット数はFEのschedule_slot_num_per_hdd_pathまたはschedule_slot_num_per_ssd_pathパラメータで設定できます。

さらに、デフォルトでは、バランシングタスク用にディスクごとに2つの別々のスロットを提供します。目的は、修復タスクによってスロットが占有されることで、高負荷ノードがバランシングによってスペースを失うことを防ぐことです。

Tablet状態ビュー

Tablet状態ビューは主にtabletの状態と、tabletの修復およびバランシングタスクの状態を確認します。これらの状態のほとんどはMaster FEノードにのみ存在します。そのため、以下のコマンドはMaster FEに直接実行する必要があります。

Tablet状態

1. グローバル状態チェック

   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列は、対応するデータベースで正常な状態にあるTabletの数を表示します。ReplicaCompactionTooSlowNum列は、対応するデータベースでバージョンが多すぎる状態にあるTabletの数を表示し、InconsistentNum列は、対応するデータベースで一貫性のないレプリカ状態にあるTabletの数を表示します。最後のTotal行は、クラスタ全体をカウントします。通常、TabletNumとHealthyNumは等しくなるべきです。等しくない場合は、どのTabletがそこにあるかをさらに確認できます。上図に示すように、ssb1データベースの1つのテーブルが正常でない場合、以下のコマンドを使用してどのテーブルかを確認できます。

`SHOW PROC '/cluster_health/tablet_health/13402';`

ここで`13402`は対応するDbIdです。

+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| ReplicaMissingTablets | VersionIncompleteTablets | ReplicaRelocatingTablets | RedundantTablets | ReplicaMissingInClusterTablets | ReplicaMissingForTagTablets | ForceRedundantTablets | ColocateMismatchTablets | ColocateRedundantTablets | NeedFurtherRepairTablets | UnrecoverableTablets | ReplicaCompactionTooSlowTablets | InconsistentTablets | OversizeTablets |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+
| 14679                 |                          |                          |                  |                                |                             |                       |                         |                          |                          |                      |                                 |                     |                 |
+-----------------------+--------------------------+--------------------------+------------------+--------------------------------+-----------------------------+-----------------------+-------------------------+--------------------------+--------------------------+----------------------+---------------------------------+---------------------+-----------------+

上の図は、特定の異常なTablet ID（14679）を示しています。後で、特定のTabletの各コピーのステータスを表示する方法を説明します。

2. テーブル（パーティション）レベルのステータス確認

   ユーザーは以下のコマンドを通じて、指定されたテーブルまたはパーティションのコピーのステータスを表示し、WHERE文を通じてステータスをフィルタリングできます。テーブルtbl1を見ると、パーティションP1とP2のステートは、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 % |
+-----------+------------+-------+---------+
```

ここでは、各BEノード上のテーブルtbl1のレプリカ数と割合、および簡単なグラフィカル表示を示しています。

4. Tabletレベルのステータス確認

   特定のTabletを特定したい場合、以下のコマンドを使用して特定のTabletのステータスを確認できます。例えば、ID 2950253のタブレットを確認する場合：

   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'; |
   +------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+

上記の図は、このタブレットに対応するデータベース、テーブル、パーティション、ロールアップテーブル、およびその他の情報を示しています。ユーザーは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             |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+
| 43734060  | 10004     | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | -8566523878520798656 |
| 29502555  | 10002     | 2       | 0           | 2                 | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | 1885826196444191611  |
| 39279319  | 10007     | 2       | 0           | -1                | 0                     | -1               | 0                    | N/A           | -1         | 784      | 0        | NORMAL | false | 2            | 1656508631294397870  |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+
```

上記の図は、対応するTabletのすべてのレプリカを示しています。ここに表示される内容はSHOW TABLETS FROM tbl1;と同じです。ただし、ここでは特定のTabletのすべてのコピーのステータスを明確に確認できます。

重複スケジューリングタスク

1. スケジュール待ちのタスクを表示

   SHOW PROC '/cluster_balance/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。スケジューリングタスクは1つのTabletのみを対象とします
* Type: タスクタイプ。REPAIR（修復）またはBALANCE（バランス）が可能です
* Status: TabletのReplicaの現在のステータス。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: Cloneタスクのデータコピー速度
* Failed Sched: タスクスケジューリング失敗回数
* Failed Running: タスク実行失敗回数
* LstAdjPrio: 最後の優先度調整時間
* CmtVer/CmtVerHash/VisibleVer/VisibleVerHash: cloneタスクのバージョン情報
* ErrMsg: タスクのスケジュールと実行時に発生するエラーメッセージ

2. 実行中タスクの表示

`SHOW PROC '/cluster_balance/running_tablets';`

結果の列は`pending_tablets`と同じ意味を持ちます。

3. 完了したタスクの表示

`SHOW PROC '/cluster_balance/history_tablets';`

デフォルトでは、最後の1,000個の完了したタスクのみを保持します。結果の列は`pending_tablets`と同じ意味を持ちます。`State`が`FINISHED`と表示されている場合、タスクは正常に完了しています。その他の場合は、`ErrMsg`列のエラー情報に基づいて具体的な理由を確認できます。

クラスター負荷とスケジューリングリソースの表示

1. クラスター負荷

   以下のコマンドでクラスターの現在の負荷を表示できます：

   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。バランス調整スケジューリングは、高負荷ノードから低負荷ノードにコピーを移動します

ユーザーは、ID 10001 の BE など、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の各データパスのディスク使用量がここに表示されます。

2. スケジューリングリソース

   ユーザーは以下のコマンドを通じて各ノードの現在のスロット使用状況を確認できます：

   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'は履歴統計のパス上でのcloneタスクのコピー率をbytes/secondsで表している。

3. 優先修復ビュー

   以下のコマンドにより、`ADMIN REPAIR TABLE'コマンドで設定された優先修復テーブルまたはパーティションを表示することができます。

   SHOW PROC '/cluster_balance/priority_repair';

   その中で、`Remaining TimeMs'は、これらの優先修復がこの時間後に優先修復キューから自動的に削除されることを示している。優先修復の失敗によりリソースが占有されることを防ぐためです。

Scheduler統計状況ビュー

Tablet CheckerとTablet Schedulerの動作中にいくつかの統計を収集しており、以下のコマンドで確認することができます：

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でチェックされたタブレットの数

• num of unhealthy tablet checked in tablet checker: Tablet Checkerでチェックされた不健全なタブレットの数

• num of tablet being added to tablet scheduler: Tablet Schedulerに送信されたタブレットの数

• num of tablet schedule round: Tablet Scheduler実行回数

• cost of tablet schedule(ms): Tablet Scheduler実行で消費された合計時間（ミリ秒）

• num of tablet being scheduled: スケジュールされたタブレットの合計数

• num of tablet being scheduled succeeded: 正常にスケジュールされたタブレットの合計数

• num of tablet being scheduled failed: スケジュールに失敗したタブレットの合計数

• num of tablet being scheduled discard: スケジュール失敗により破棄されたタブレットの合計数

• num of tablet priority upgraded: タブレット優先度アップグレードの数

• num of tablet priority downgraded: タブレット優先度ダウングレードの数

• num of clone task: 生成されたcloneタスクの数

• num of clone task succeeded: 成功したcloneタスクの数

• num of clone task failed: 失敗したcloneタスクの数

• num of clone task timeout: タイムアウトしたcloneタスクの数

• num of replica missing error: ステータスがレプリカ不足としてチェックされたタブレットの数

• num of replica version missing error: バージョン不足ステータスでチェックされたタブレットの数（この統計にはnum of replica relocatingとnum of replica missing in cluster errorが含まれます）

• num of replica relocation: レプリカ再配置の数

• num of replica redundant error: チェックされたステータスがレプリカ冗長であるタブレットの数

• num of replica missing in cluster error: 対応するクラスタから欠落していることを示すステータスでチェックされたタブレットの数

• num of balance scheduled: バランス調整スケジューリング試行回数

Note

上記の状態は過去の累積値のみです。これらの統計情報はFEログでも定期的に出力され、そこでの括弧内の値は前回の出力以降の各統計値の変化数を表しています。

関連設定手順

調整可能なパラメータ

以下の調整可能なパラメータは、すべてfe.confの設定可能なパラメータです。

• use_new_tablet_scheduler

  • 説明: 新しいレプリカスケジューリングモードを有効にするかどうか。新しいレプリカスケジューリング方法は、この文書で紹介されるレプリカスケジューリング方法です。有効にする場合、disable_colocate_joinはtrueである必要があります。新しいスケジューリング戦略は現在のところco-locationテーブルのデータフラグメンテーションスケジューリングをサポートしていないためです。
  • デフォルト値: true
  • 重要度: 高

• tablet_repair_delay_factor_second

  • 注意: 異なるスケジューリング優先度に対して、修復開始まで異なる時間を遅延させます。定期的な再起動やアップグレードの過程で、大量の不要なレプリカ修復タスクが発生することを防ぐためです。このパラメータは参照係数です。HIGH優先度の場合、遅延は参照係数 * 1、NORMAL優先度の場合、遅延は参照係数 * 2、LOW優先度の場合、遅延は参照係数 * 3です。つまり、優先度が低いほど、遅延待機時間が長くなります。ユーザーができるだけ早くコピーを修復したい場合は、このパラメータを適切に減らすことができます。
  • デフォルト値: 60秒
  • 重要度: 高

• schedule_slot_num_per_path

  • 注意: レプリカ修復用に各ディスクに割り当てられるデフォルトのスロット数。この数は、ディスクが同時に実行できるレプリカ修復タスクの数を表します。コピーをより速く修復したい場合は、このパラメータを適切に調整できます。単一値が高いほど、IOへの影響が大きくなります。
  • デフォルト値: 2
  • 重要度: 高

• balance_load_score_threshold

  • 説明: クラスタ均衡のしきい値。デフォルトは0.1、または10%です。BEノードの負荷コアが平均負荷コアの10%を超えて高くまたは低くない場合、そのノードは均衡していると考えます。クラスタ負荷をより均等にしたい場合は、このパラメータを適切に調整できます。
  • デフォルト値: 0.1
  • 重要度:

• storage_high_watermark_usage_percent と storage_min_left_capacity_bytes

  • 説明: これら2つのパラメータは、ディスクの最大スペース使用率の上限と最小残存スペースの下限をそれぞれ表します。ディスクのスペース使用率が上限を超えるか、残存スペースが下限を下回る場合、そのディスクはバランス調整スケジューリングの宛先アドレスとして使用されなくなります。
  • デフォルト値: 0.85と2097152000（2GB）
  • 重要度:

• disable_balance

  • 説明: バランス調整機能をオフにするかどうかを制御します。レプリカが均衡状態にある時、ALTER TABLEなどの一部の機能が禁止されます。均衡は長時間続く可能性があります。そのため、ユーザーが禁止された操作をできるだけ早く実行したい場合、このパラメータをtrueに設定してバランス調整スケジューリングをオフにできます。
  • デフォルト値: false
  • 重要度:

以下の調整可能なパラメータは、すべてbe.confの設定可能なパラメータです。

• clone_worker_count

  • 説明: コピー均衡の速度に影響します。ディスクプレッシャーが低い場合、このパラメータを調整してレプリカバランシングを高速化できます。
  • デフォルト: 3
  • 重要度: 中

調整不可能なパラメータ

以下のパラメータは現在修正をサポートしておらず、説明のみを目的としています。

• Tablet Checkerスケジューリング間隔

  Tablet Checkerは20秒ごとにチェックをスケジューリングします。

• Tablet Schedulerスケジューリング間隔

  Tablet Schedulerは5秒ごとにスケジューリングします

• Tablet Schedulerのバッチ当たりスケジュール数

  Tablet Schedulerは一度に最大50のタブレットをスケジューリングします。

• Tablet Schedulerの最大待機スケジュールおよび動作中のタスク数

  待機タスクと実行中のタスクの最大数は2000です。2000を超える場合、Tablet CheckerはTablet Schedulerに新しいスケジューリングタスクを生成しなくなります。

• Tablet Schedulerの最大バランスタスク数

  バランスタスクの最大数は500です。500を超える場合、新しいバランシングタスクは実行されません。

• バランスタスク用ディスク当たりスロット数

  バランスタスク用のディスク当たりスロット数は2です。このスロットはレプリカ修復に使用されるスロットとは独立しています。

• クラスタ均衡の更新間隔

  Tablet Schedulerは20秒ごとにクラスタの負荷スコアを再計算します。

• Cloneタスクの最小および最大タイムアウト

  cloneタスクのタイムアウト時間範囲は3分から2時間です。具体的なタイムアウトはタブレットのサイズによって計算されます。計算式は（タブレットサイズ）/（5MB/s）です。cloneタスクが3回失敗すると、タスクは終了します。

• 動的優先度調整戦略

  最小優先度調整間隔は5分です。タブレットのスケジュールが5回失敗すると優先度が下がります。タブレットが30分間スケジュールされない場合、優先度が上がります。

関連する問題

• 一部の場合、デフォルトのレプリカ修復およびバランス調整戦略により、ネットワークが満杯になる可能性があります（主にギガビットネットワークカードとBE当たりの大量のディスクの場合）。この時点で、同時バランス調整および修復タスクの数を減らすため、一部のパラメータを調整する必要があります。

• Colocate Tableのコピーに対する現在のバランス調整戦略では、同じTabletのコピーが同じホストのBEに分散されないことを保証できません。ただし、Colocate Tableのコピーの修復戦略はこの分散エラーを検出して修正します。しかし、修正後にバランス調整戦略がレプリカを不均衡とみなして再バランスする可能性があります。その結果、2つの状態の継続的な交互により、Colocate Groupが安定を達成できません。この状況を考慮して、Colocate属性を使用する場合は、レプリカが同じホストに分散される確率を減らすため、クラスタの同型性を確保することを推奨します。

ベストプラクティス

クラスタのレプリカ修復とバランス調整の進行の制御と管理

ほとんどの場合、Dorisはデフォルトのパラメータ設定により、自動的にレプリカ修復とクラスタバランス調整を実行できます。しかし、一部の場合では、特別な目的を達成するため、パラメータを調整して手動で介入する必要があります。例えば、テーブルやパーティションの修復を優先する、クラスタ負荷を減らすためにクラスタバランス調整を無効にする、非colocationテーブルデータの修復を優先するなどです。

このセクションでは、パラメータを修正してクラスタのレプリカ修復とバランス調整の進行を制御・管理する方法について説明します。

1. 破損したレプリカの削除

   一部の場合、Dorisは一部の破損したレプリカを自動的に検出できず、破損したレプリカで頻繁なクエリやインポートエラーが発生する可能性があります。この場合、破損したコピーを手動で削除する必要があります。この方法は以下に使用できます：-235エラーの原因となる高いバージョン番号のコピーを削除する、ファイルの破損したコピーを削除するなど。

   まず、対応するコピーのタブレットIDを見つけます。例えば10001とし、show tablet 10001;を使用してshow proc文を実行し、対応するタブレットの各コピーの詳細を確認します。

   削除するコピーのbackend idが20001であると仮定して、以下の文を実行してコピーをbadとしてマークします。

   ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "10001", "backend_id" = "20001", "status" = "bad");

この時点で、show proc文を再度実行すると、対応するコピーのIsBad列の値がtrueになっていることが確認できます。

badとマークされたレプリカは、インポートやクエリに参加しなくなります。レプリカ修復ロジックが同時に新しいレプリカを自動的に補充します。2.

2. テーブルまたはパーティションの修復を優先する

   help admin repair table;でヘルプを確認してください。このコマンドは、指定されたテーブルまたはパーティションのtabletを優先的に修復しようと試みます。

3. バランシングタスクを停止する

   バランシングタスクは、いくらかのネットワーク帯域幅とIOリソースを消費します。新しいバランシングタスクの生成を停止したい場合は、以下のコマンドで実行できます。

   ADMIN SET FRONTEND CONFIG ("disable_balance" = "true");

4. すべてのレプリカスケジューリングタスクを停止する

   Copyスケジューリングタスクには、バランシングおよび修復タスクが含まれます。これらのタスクは、一部のネットワーク帯域幅とIOリソースを消費します。すべてのレプリカスケジューリングタスク（既に実行中のものを除く、colocation tablesとcommon tablesを含む）は、以下のコマンドで停止できます。

   ADMIN SET FRONTEND CONFIG ("disable_tablet_scheduler" = "true");

5. すべてのcolocationテーブルに対してコピースケジューリングタスクを停止します。

   colocationテーブルのコピースケジューリングは、通常のテーブルとは独立して実行されます。場合によっては、ユーザーはcolocationテーブルのバランシングと修復を最初に停止し、以下のコマンドを使用して通常のテーブル修復にクラスターリソースを使用したい場合があります。

   ADMIN SET FRONTEND CONFIG ("disable_colocate_balance" = "true");

6. より保守的な戦略を使用してレプリカを修復する

   Dorisは、レプリカの欠損やBEのダウンタイムなどを検出した際に自動的にレプリカを修復します。ただし、ジッター（例：BEが短時間ダウンしている）によって引き起こされる一部のエラーを減らすため、Dorisはこれらのタスクのトリガーを遅延させます。

   • tablet_repair_delay_factor_secondパラメータ。デフォルトは60秒です。修復タスクの優先度に応じて、修復タスクのトリガーを60秒、120秒、または180秒遅延させます。この時間を延長することで、より長い例外を許容し、以下のコマンドを使用して不要な修復タスクのトリガーを回避できます。

   ADMIN SET FRONTEND CONFIG ("tablet_repair_delay_factor_second" = "120");

7. コロケーショングループの再分散をトリガーするためにより保守的な戦略を使用する

   コロケーショングループの再分散には、大量のタブレット移行が伴う可能性があります。colocate_group_relocate_delay_secondは再分散トリガーの遅延を制御するために使用されます。デフォルトは1800秒です。BEノードが長時間オフラインになる可能性がある場合、このパラメータを増やして不要な再分散を回避することを試すことができます。

   ADMIN SET FRONTEND CONFIG ("colocate_group_relocate_delay_second" = "3600");

8. より高速なレプリカバランシング

   Dorisのレプリカバランシングロジックは、レプリカ移行の目的で、まず通常のレプリカを追加してから古いものを削除します。古いレプリカを削除する際、Dorisはバランシングタスクがimportタスクに影響を与えることを避けるため、このレプリカ上で既に開始されているimportタスクの完了を待機します。しかし、これによりバランシングロジックの実行速度が低下します。この場合、以下のパラメータを変更することで、Dorisにこの待機を無視させ、古いレプリカを直接削除させることができます。

   ADMIN SET FRONTEND CONFIG ("enable_force_drop_redundant_replica" = "true");

この操作により、バランシング中に一部のインポートタスクが失敗する可能性がありますが（再試行が必要）、バランシングを大幅に高速化します。

全体的に、クラスタを迅速に正常状態に戻す必要がある場合は、以下の方針に沿って対処することを検討してください。

1. 高最適化タスクがエラーを報告する原因となっているタブレットを見つけ、問題のあるコピーをbadに設定する。
2. admin repair文で一部のテーブルを修復する。
3. レプリカバランシングロジックを停止してクラスタリソースの占有を避け、クラスタが復旧した後に再度有効にする。
4. より保守的な戦略を使用して修復タスクをトリガーし、頻繁なBEダウンタイムによって引き起こされる雪崩効果に対処する。
5. colocationテーブルのスケジューリングタスクをオンデマンドで無効にし、他の高最適化データの修復にクラスタリソースを集中させる。