データレプリカ管理

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

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

用語の解釈

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

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

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は、レプリカノードを選択する際に、同じホストの異なるBEに同じTabletのコピーをデプロイしません。これにより、同じホスト上のすべての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分間スケジュールされない場合、優先度が上げられます。
• 同じタブレットタスクの優先度調整は少なくとも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ノード負荷

クラスタ内の各バックエンドの負荷分散を表すためにCluster LoadStatistics（CLS）を使用します。Tablet Schedulerはこの統計に基づいてクラスタ均衡をトリガーします。現在、ディスク使用量とコピー数を使用して各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 * ディスク使用率 - 0.5

重み係数は、ディスク使用率が高すぎる場合、バックエンド負荷スコアが高くなり、BE負荷ができるだけ早く削減されることを保証します。

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

Partition

パーティションリバランシングの主要なアイデアは、パーティションの偏りを減らすことです。パーティションの偏りは、すべてのbe上のパーティションの最大レプリカ数とすべてのbe上の最小レプリカ数の差として定義されます。

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

偏り情報

偏り情報はClusterBalanceInfoによって表現されます。partitionInfoBySkewはキーがパーティションの偏りであるマルチマップなので、最大偏りパーティションを簡単に取得できます。beByTotalReplicaCountはキーがバックエンドの総レプリカ数であるマルチマップです。

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状態ビューは主にタブレットの状態、およびタブレット修復とバランシングタスクの状態を確認します。これらの状態のほとんどは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の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             |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+
| 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：REPLICA\_MISSING（レプリカ欠落）などのTabletの現在のステータス
* 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タスクのデータコピーRate
* 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はライアルタイムが正常でオフラインでないことを意味します。
* 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の各データパスのディスク使用量がここに表示されます。

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によってチェックされた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: tabletの優先度アップグレード回数

• num of tablet priority downgraded: tabletの優先度ダウングレード回数

• 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: レプリカが不足していると確認されたtablet数

• num of replica version missing error: バージョンが不足している状態と確認されたtablet数（この統計にはnum of replica relocatingとnum of replica missing in cluster errorが含まれます）

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

• num of replica redundant error: レプリカが冗長であると確認されたtablet数

• num of replica missing in cluster error: 対応するクラスターから不足していることを示す状態と確認されたtablet数

• 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をスケジュールします。

• Tablet Schedulerの最大待機スケジュールと実行中タスク数

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

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

  バランスタスクの最大数は500です。500を超えると、新しいバランシングタスクは発生しません。

• バランシングタスクのディスクあたりスロット数

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

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

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

• Cloneタスクの最小・最大タイムアウト

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

• 動的優先度調整戦略

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

関連する問題

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

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

ベストプラクティス

クラスターのレプリカ修復とバランシングの進捗を制御・管理する

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

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

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.

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は、バランシングタスクがインポートタスクに影響を与えることを避けるために、このレプリカで既に開始されているインポートタスクの完了を待機します。しかし、これによりバランシングロジックの実行速度が低下します。この場合、以下のパラメータを変更することで、Dorisにこの待機を無視させ、古いレプリカを直接削除させることができます。

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

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

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

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