データレプリカ管理

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

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

用語解説

1. Tablet: Dorisテーブルの論理的な断片化で、1つのテーブルは複数のフラグメントを持ちます。
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

   レプリケーション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は、レプリカノードを選択する際、同じホストの異なるBE上に同じTabletのコピーをデプロイしません。これにより、同じホスト上のすべてのBEが非アクティブになっても、すべてのコピーが失われることがないことを保証します。

スケジューリング優先度

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

1. VERY_HIGH

   • REDUNDANT。重複冗長のあるスライスに対して、優先度を与えます。論理的には、重複冗長は最も緊急度が低いですが、処理が最も速く、リソース（ディスク容量など）を迅速に解放できるため、優先度を与えます。
   • FORCE_REDUNDANT。同上。

2. HIGH

   • REPLICA_MISSINGで、ほとんどのコピーが不足している（例：3コピーのうち2コピーが不足）
   • VERSION_INCOMPLETEで、ほとんどのコピーが不足している
   • COLOCATE_MISMATCHCollocationテーブルに関連する断片化ができるだけ早く修復されることを希望します。
   • 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の主なアイデアは、パーティションのスキューを減らすことです。パーティションのスキューは、すべてのbe上のパーティションの最大レプリカ数とすべてのbe上の最小レプリカ数の差として定義されます。

そのため、レプリカ数のみを考慮し、レプリカサイズ（ディスク使用量）は考慮しません。 移動を少なくするために、cluster & partitionの2次元を持つTwoDimensionalGreedyAlgoを使用します。最大スキューパーティションをリバランスしたい場合、クラスターのスキューを削減する移動を優先します。

スキュー情報

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

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

複数の最大スキューパーティションを取得した場合、移動を計算するために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\_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: 生成されたクローンタスク数

• num of clone task succeeded: 成功したクローンタスク数

• num of clone task failed: 失敗したクローンタスク数

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

• 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: バランス調整されたスケジューリング試行数

注意

上記の状態は履歴累積値のみです。これらの統計は定期的にFEログに出力され、括弧内の値は統計情報の依存関係に基づく前回出力以降の各統計値の変化数を表します。

関連する設定手順

調整可能なパラメータ

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

• use_new_tablet_scheduler

  • 説明: 新しいレプリカスケジューリングモードを有効にするかどうか。新しいレプリカスケジューリング方法は、このドキュメントで紹介されているレプリカスケジューリング方法です。有効にする場合、disable_colocate_join を true にする必要があります。新しいスケジューリング戦略では、現在のところコロケーションテーブルのデータフラグメンテーションスケジューリングをサポートしていないためです。
  • デフォルト値：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 Taskの最小および最大タイムアウト

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

• 動的優先度調整戦略

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

関連する問題

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

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

ベストプラクティス

クラスターのレプリカ修復とバランシングの進行状況の制御と管理

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

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

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. すべてのレプリカスケジューリングタスクを停止する

   コピースケジューリングタスクには、バランシングタスクと修復タスクが含まれます。これらのタスクは一部のネットワーク帯域幅とIOリソースを消費します。すべてのレプリカスケジューリングタスク（すでに実行中のものを除く、colocation 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テーブルのスケジューリングタスクをオンデマンドで無効にし、クラスターリソースを他の高最適化データの修復に集中させる。