データレプリカ管理

バージョン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

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

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 Checkerは異な状態に応じて、スケジューリング待ちの断片に異なる優先度を与えます。高優先度の断片が最初にスケジューリングされます。現在、いくつかの優先度があります。

スケジューリング優先度

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負荷スコアとして使用しています。スコアが高いほど、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は20秒ごとにCLSを更新します。

Partition

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

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

スキュー情報

スキュー情報はClusterBalanceInfoで表されます。partitionInfoBySkewはキーがパーティションのスキューであるmultimapで、最大スキューパーティションを簡単に取得できます。beByTotalReplicaCountはキーがバックエンドの総レプリカ数である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状態ビューは主にタブレットの状態と、タブレット修復およびバランシングタスクの状態を見ます。これらの状態のほとんどは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に対応するデータベース、テーブル、パーティション、roll-upテーブル、およびその他の情報を示しています。ユーザーは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タスクのDataコピーレート
* 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は履歴統計のパス上でのクローンタスクのコピー率を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: バランス調整スケジューリング試行回数

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秒ごとにクラスターの負荷スコアを再計算します。

• クローンタスクの最小・最大タイムアウト

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

• 動的優先度調整戦略

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

関連課題

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

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

ベストプラクティス

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

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

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

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;でヘルプを表示します。このコマンドは、指定されたテーブルまたはパーティションのタブレットを優先的に修復しようとします。

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

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

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

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

   コピースケジューリングタスクには、バランシングタスクと修復タスクが含まれます。これらのタスクはネットワーク帯域幅と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");

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

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

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