メインコンテンツまでスキップ
バージョン: 2.5

レプリカ管理

用語

  • Tablet: テーブルの論理的なスライス。テーブルは複数のTabletを持つ。
  • レプリカ: Tabletのコピー。デフォルトで1つのTabletに対して3つのレプリカがある。
  • 健全なレプリカ: バックエンドが生存しており、バージョンが完全なレプリカ。
  • TabletChecker (TC): 常駐のバックグラウンドスレッドで、定期的にすべてのTabletをスキャンし、その状態に基づいてTabletをTabletSchedulerに送るかどうかを決定する。
  • TabletScheduler (TS): TabletCheckerから送られてきたTabletを処理し、クラスターのレプリカバランシングも行う常駐のバックグラウンドスレッド。
  • TabletSchedCtx (TSC): Tabletのラッパー。TCによって選択されたTabletはTSCとしてカプセル化され、TSに送られる。
  • 記憶媒体: StarRocksは、SSDやHDDを含むパーティショングラニュラリティの異なる記憶媒体をサポートしている。レプリカのスケジューリングは、異なる記憶媒体に対して異なる。

ステータス

レプリカステータス

レプリカの健康状態は以下の通りです。

  • BAD

レプリカが破損している。これには、ディスク障害やバグなどによるレプリカの回復不能な損傷が含まれるが、これに限定されない。

  • VERSION_MISSING

各バッチインポートは1つのデータバージョンに対応している。1つのレプリカにいくつかの連続したバージョンがあるはずです。インポートエラーにより、一部のレプリカはデータのバージョンが不完全になることがあります。

  • HEALTHY

レプリカは正しいデータを持ち、その場所にあるBEノードは正常な状態にある(正常なハートビートがあり、オフラインになる過程にない)。

Tabletステータス

Tabletの健康状態は、そのすべてのレプリカの状態によって決まります。

  • REPLICA_MISSING

レプリカが欠落している。つまり、生存しているレプリカの数が期待されるレプリカの数より少ない。

  • VERSION_INCOMPLETE

生存しているレプリカの数は期待される数以上だが、健康なレプリカの数が期待される数より少ない。

  • REPLICA_RELOCATING

完全なバージョンを持つ生存しているレプリカの数が replication num と等しい。しかし、一部のレプリカが存在するBEノードが利用できない(例:廃止状態)。

  • REPLICA_MISSING_IN_CLUSTER

複数のクラスターを使用している場合、健康なレプリカの数は期待される数以上だが、対応するクラスター内のレプリカの数が期待される数より少ない。

  • REDUNDANT

レプリカの冗長性。すべての健康なレプリカが対応するクラスターにあるが、冗長な利用不可のレプリカのためにレプリカの総数が期待される数より多い。

  • FORCE_REDUNDANT

これは特別なステータスです。期待されるレプリカの数が利用可能なノードの数以上であり、Tabletがレプリカ欠落状態にある場合にのみ発生します。この場合、新しいレプリカを作成するために利用可能なノードを確保するために、まず1つのレプリカを削除する必要があります。

  • COLOCATE_MISMATCH

Colocation属性のTabletステータスで、シャード化されたレプリカがColocation Groupで指定された分布と一致しないことを示します。

  • COLOCATE_REDUNDANT

Colocation属性のTabletステータスで、ColocationテーブルのTabletレプリカが冗長であることを示します。

  • HEALTHY

健康なTablet。

レプリカ修復

TabletCheckerは定期的にすべてのTabletの状態をチェックします。健康でないTabletはTabletSchedulerに引き渡され、スケジューリングと修復が行われます。修復はBEでクローンタスクとして行われます。FEはクローンタスクの生成を担当します。

注1: レプリカ修復の主な考え方は、まず新しいレプリカを作成または修正して目標値に達し、次に冗長なレプリカを削除することです。 注2: クローンタスクは、ターゲットデータをリモートBEから宛先BEにコピーすることです。

異なる状態に対して、異なる方法で修復を行います。

  1. REPLICA_MISSING/REPLICA_RELOCATING 利用可能なBEノードを宛先BEとして選択します。健康なレプリカをソースとして選択します。クローンタスクは、ソースから宛先BEに完全なレプリカをコピーします。レプリカ補充のために、記憶媒体に関係なく利用可能なBEノードが選択されます。

  2. VERSION_INCOMPLETE 比較的完全なレプリカを宛先として選択します。健康なレプリカをソースとして選択します。クローンタスクは、ソースから宛先に欠落しているバージョンをコピーします。

  3. REPLICA_MISSING_IN_CLUSTER このステータスはREPLICA_MISSINGと同じ方法で処理されます。

  4. REDUNDANT 通常、レプリカ修復後、Tabletには冗長なレプリカが残ります。冗長なレプリカを選択して削除します。冗長なレプリカの選択は次の順序に従います:

    • レプリカが存在するBEがすでにオフラインである
    • レプリカが破損している
    • レプリカが存在するBEが接続不良またはオフラインになる過程にある
    • レプリカがCLONE状態にある(クローンタスク実行中の中間状態)
    • レプリカが欠落したバージョンを持っている
    • レプリカが存在するクラスターが間違っている
    • レプリカが存在するBEノードが重負荷である
  5. FORCE_REDUNDANT Tabletには欠落したレプリカがあるが、新しいレプリカを作成するための利用可能なノードがない。この場合、まずレプリカを削除して新しいレプリカを作成するためのノードを確保する必要があります。レプリカの削除順序はREDUNDANTと同じです。

  6. COLOCATE_MISMATCH Colocation Groupで指定されたBEノードの1つをレプリカ補充の宛先ノードとして選択します。

  7. COLOCATE_REDUNDANT Colocation Groupで指定されていないBEノード上のレプリカを削除します。

StarRocksは、同じTabletのレプリカを同じホストの異なるBEsにデプロイしないため、同じホストのすべてのBEsが故障しても、一部のレプリカは生存しています。

レプリカスケジューリング

スケジューリングの優先順位

TabletSchedulerでスケジューリングを待っているTabletは、その状態に応じて異なる優先順位が与えられます。優先順位の高いTabletが最初にスケジューリングされます。優先順位のレベルは次の通りです。

  • VERY_HIGH

  • REDUNDANT状態にある。冗長なレプリカを持つTabletは非常に高い優先順位が与えられます。レプリカの冗長性は最も緊急ではありませんが、処理が最も速く、リソース(ディスクスペースなど)を解放します。

  • FORCE_REDUNDANT状態にある。上記と同じ。

  • HIGH

  • REPLICA_MISSING状態で、ほとんどのレプリカが欠落している(例:3つのレプリカのうち2つが欠落している)

  • VERSION_INCOMPLETE状態で、ほとんどのレプリカが欠落したバージョンを持っている

  • COLOCATE_MISMATCH状態にある。Colocationテーブルに関連するTabletはできるだけ早く修正されます。

  • COLOCATE_REDUNDANT状態にある。

  • NORMAL

  • REPLICA_MISSING状態だが、ほとんどのレプリカが生存している(例:3つのレプリカのうち1つが欠落している)

  • VERSION_INCOMPLETE状態だが、ほとんどのレプリカが完全なバージョンを持っている

  • REPLICA_RELOCATING状態で、ほとんどのレプリカが再配置を必要としている(例:3つのコピーのうち2つ)

  • LOW

  • REPLICA_MISSING_IN_CLUSTER状態にある

  • REPLICA_RELOCATING状態だが、ほとんどのレプリカが安定している

手動で決定された優先順位

システムは自動的にスケジューリングの優先順位を決定します。しかし、ユーザーが特定のTabletをより早く修復したい場合があります。そのため、特定のテーブルまたはパーティションのTabletを優先的に修復するように指定するコマンドを提供しています。

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

このコマンドは、問題のあるTabletに VERY_HIGH 優先順位を与え、最初に修復されるようにTCに指示します。

注: このコマンドは修復の成功を保証するものではなく、優先順位はTSのスケジューリングに伴って変わります。この情報は、Leader FEが変更または再起動されると失われます。

優先順位のキャンセルは次のコマンドで行えます。

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

優先順位スケジューリング

優先順位付けにより、深刻に損傷したTabletが最初に修復されます。しかし、高優先度の修復タスクが失敗し続けると、低優先度のタスクがスケジュールされないままになります。そのため、各タスクの状態に基づいて優先順位を動的に調整し、すべてのタスクがスケジュールされる機会を確保します。

  • スケジューリングが5回連続で失敗した場合(例:リソースを取得できない、適切なソースまたは宛先を見つけられないなど)、タスクは優先順位を下げられます。
  • タスクが30分間スケジュールされていない場合、優先順位が上げられます。
  • タスクの優先順位は5分以内に2回調整されることはありません。

初期の優先順位レベルが重視されるように、VERY_HIGH タスクは最大で NORMAL にしか優先順位を下げられず、LOW タスクは最大で HIGH にしか優先順位を上げられません。優先順位の調整は、ユーザーによって手動で設定されたタスクにも適用されます。

レプリカバランシング

StarRocksはクラスター内で自動的にレプリカバランシングを行います。バランシングの主な考え方は、低負荷のノードにレプリカを作成し、高負荷のノードからレプリカを削除することです。同じクラスター内の異なるBEノードに複数の記憶媒体が存在する場合があります。バランシング後にTabletが元の記憶媒体に残るように、BEノードは記憶媒体に基づいて分割され、負荷バランシングが賢くスケジュールされます。

同様に、レプリカバランシングは、同じTabletのレプリカが同じホストのBEsにデプロイされないことを保証します。

BEノードの負荷

ClusterLoadStatistics (CLS) は、クラスター内の各バックエンドの負荷バランスを示し、TabletSchedulerにクラスターをバランスさせるトリガーを提供します。現在、**Disk Utilization****Number of Replicas** を使用して各BEの loadScore を計算しています。スコアが高いほど、BEの負荷が重いことを示します。

capacityCoefficientreplicaNumCoefficient(合計で1)は、それぞれ Disk UtilizationNumber of Replicas の重み付け係数です。capacityCoefficient は実際のディスク使用量に応じて動的に調整されます。BEの全体的なディスク使用率が50%未満の場合、capacityCoefficient の値は0.5です。ディスク使用率が75%以上の場合(FEの設定項目 capacity_used_percent_high_water で設定可能)、値は1です。使用率が50%から75%の間の場合、次の式に基づいて重み係数がスムーズに増加します:

capacityCoefficient= 2 * disk utilization - 0.5

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

TabletSchedulerは1分ごとにCLSを更新します。

バランシングポリシー

TabletSchedulerは、各スケジューリングラウンドでLoadBalancerを通じてバランスを取るための候補として一定数の健康なTabletを選択し、これらの候補スライスに基づいて将来のスケジューリングを調整します。

リソース制御

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

さらに、デフォルトでは、各ディスクに対してレプリカバランシング用に2つのスロットが割り当てられています。これは、重負荷のノードが修復タスクによって占有され、バランシングによってスペースを解放できないことを防ぐためです。

レプリカステータスの表示

レプリカステータスは Leader FEノードにのみ存在します。したがって、以下のコマンドはLeader FEに直接接続して実行する必要があります。

レプリカステータスの表示

  1. グローバルステータスチェック
    SHOW PROC '/statistic'; コマンドを使用して、クラスター全体のレプリカステータスを表示できます。

    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
    | DbId | DbName | TableNum | PartitionNum | IndexNum | TabletNum | ReplicaNum | UnhealthyTabletNum | InconsistentTabletNum |
    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+
    | 35153636 | default_cluster:DF_Newrisk | 3 | 3 | 3 | 96 | 288 | 0 | 0 |
    | 48297972 | default_cluster:PaperData | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
    | 5909381 | default_cluster:UM_TEST | 7 | 7 | 10 | 320 | 960 | 1 | 0 |
    | Total | 240 | 10 | 10 | 13 | 416 | 1248 | 1 | 0 |
    +----------+-----------------------------+----------+--------------+----------+-----------+------------+--------------------+-----------------------+

UnhealthyTabletNum 列は、対応するデータベースにどれだけの不健康なTabletがあるかを示します。InconsistentTabletNum 列は、対応するデータベースにどれだけのレプリカ不一致状態のTabletがあるかを示します。最後の Total 行は、クラスター全体の統計を示します。通常、UnhealthyTabletNumInconsistentTabletNum はゼロであるべきです。ゼロでない場合は、さらにTabletの情報を確認できます。上記のように、UM_TEST データベースに不健康な状態のTabletが1つあるため、次のコマンドを使用してどのTabletかを確認できます。

SHOW PROC '/statistic/5909381';
ここで 5909381 は対応するDbIdです。

+------------------+---------------------+
| UnhealthyTablets | InconsistentTablets |
+------------------+---------------------+
| [40467980] | [] |
+------------------+---------------------+

上記の結果は、特定の不健康なTablet ID(40467980)を示しています。次に、特定のTabletの各レプリカの状態を確認する方法を説明します。

  1. テーブル(パーティション)レベルのステータスチェック
    ユーザーは、次のコマンドを使用して特定のテーブルまたはパーティションのレプリカの状態を確認でき、WHERE文で状態をフィルタリングできます。たとえば、tbl1p1p2 のNORMALレプリカの状態を表示するには、次のようにします。
    ADMIN 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 列は追加情報を示します。 ADMIN SHOW REPLICA STATUS コマンドは、主にレプリカの健康状態を確認するために使用されます。ユーザーは次のコマンドで追加情報を表示することもできます。

    SHOW TABLET 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 列はレプリカ自体の健康状態を表すものではなく、特定のタスク(例:CLONESCHEMA_CHANGEROLLUP など)におけるレプリカの状態を表します。

さらに、ユーザーは次のコマンドでレプリカが均等に分布しているかどうかを確認できます
ADMIN 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ノード上のレプリカ数、パーセンテージ、簡単なグラフィカル表示が含まれています。

Tabletレベルのステータスチェック

ユーザーは次のコマンドを使用して特定のTabletの状態を確認できます。たとえば、ID 29502553のTabletの状態を確認するには、次のようにします。

SHOW TABLET 29502553;

+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| DbName | TableName | PartitionName | IndexName | DbId | TableId | PartitionId | IndexId | IsSync | DetailCmd |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+
| default_cluster:test | test | test | test | 29502391 | 29502428 | 29502427 | 29502428 | true | SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553'; |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+

上記は、Tabletに対応するデータベース、テーブル、パーティション、インデックスなどの情報を示しています。ユーザーは DetailCmd にあるコマンドをコピーして詳細を確認できます。 SHOW PROC '/dbs/29502391/29502428/partitions/29502427/29502428/29502553';

+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State | IsBad | VersionCount | PathHash | MetaUrl | CompactionStatus |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+
| 43734060 | 10004 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | -8566523878520798656 | url | url |
| 29502555 | 10002 | 2 | 0 | 2 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1885826196444191611 | url | url |
| 39279319 | 10007 | 2 | 0 | -1 | 0 | -1 | 0 | N/A | -1 | 784 | 0 | NORMAL | false | 2 | 1656508631294397870 | url | url |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+

上記は、対応するTabletのすべてのレプリカを示しています。ここで示されている内容は SHOW TABLET FROM tbl1; と同じですが、ここでは特定のTabletのすべてのレプリカの状態を明確に確認できます。

レプリカのスケジューリングタスク

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。各Tabletに対するタスク
    • Type: タスクの種類、REPAIRまたはBALANCE
    • Status: Tabletの現在の状態、例えば REPLICA_MISSING
    • State: このスケジューリングタスクの状態、PENDING/RUNNING/FINISHED/CANCELLED/TIMEOUT/UNEXPECTED のいずれか
    • OrigPrio: 初期優先順位
    • DynmPrio: 動的優先順位
    • SrcBe: ソースBEノードのID
    • SrcPath: ソースBEノードのパス
    • DestBe: 宛先BEノードのID
    • DestPath: 宛先BEノードのパス
    • Timeout: タスクが正常にスケジュールされた場合、タスクのタイムアウトが秒単位で表示されます
    • Create: タスクが作成された時間
    • LstSched: タスクが最後にスケジュールされた時間
    • LstVisit: タスクが最後にアクセスされた時間。ここでの「アクセス」とは、スケジューリング、タスク実行報告などを指します。
    • Finished: タスクが完了した時間
    • Rate: クローンタスクのデータコピー速度
    • FailedSched: タスクスケジューリングが失敗した回数
    • FailedRunning: タスク実行が失敗した回数
    • LstAdjPrio: タスクの優先順位が最後に調整された時間
    • CmtVer/CmtVerHash/VisibleVer/VisibleVerHash: クローンタスクを実行するために使用されるバージョン情報
    • ErrMsg: タスクがスケジュールされ、実行されたときのエラーメッセージ

実行中のタスクを表示

SHOW PROC '/cluster_balance/running_tablets';
同じプロパティが使用されます。詳細は pending tablets を参照してください。

完了したタスクを表示

SHOW PROC '/cluster_balance/history_tablets';
デフォルトでは、最後の1000件の完了したタスクのみを保持します。同じプロパティが使用されます。詳細は pending tablets を参照してください。StateFINISHED の場合、タスクが正常に完了したことを意味します。それ以外の場合は、失敗したタスクの理由を ErrMsg で確認してください。