レプリカの管理
このトピックでは、StarRocks クラスター内のデータレプリカの管理方法について説明します。
概要
StarRocks は、データの高可用性を保証するためにマルチレプリカ戦略を採用しています。テーブルを作成する際には、テーブルプロパティ replication_num を使用してテーブルのレプリカ数を指定する必要があります（デフォルト値: 3）。ロードトランザクションが開始されると、データは指定された数のレプリカに同時にロードされます。データがレプリカの過半数に保存された後にのみ、トランザクションは成功として返されます。詳細については、 Write quorum を参照してください。それでも、StarRocks は、より良いロードパフォーマンスを達成するために、テーブルに対して低い書き込みクォーラムを指定することを許可しています。
StarRocks は、異なる BE ノードに複数のレプリカを保存します。たとえば、テーブルに 3 つのレプリカを保存したい場合、StarRocks クラスターに少なくとも 3 つの BE ノードをデプロイする必要があります。レプリカのいずれかが失敗した場合、StarRocks は他の BE ノードから健康なレプリカを部分的または完全にクローンして、失敗したレプリカを修復します。マルチバージョン同時実行制御 (MVCC) 技術を使用することで、StarRocks はこれらのマルチバージョンデータの物理コピーを複製することにより、レプリカの修復を加速します。
マルチレプリカテーブルへのデータロード
ロードトランザクションのルーチンは次のとおりです。
-
クライアントが FE にロードリクエストを送信します。
-
FE はこのロードトランザクションのコーディネータ BE ノードを選択し、トランザクションの実行計画を生成します。
-
コーディネータ BE ノードがクライアントからロードするデータを読み取ります。
-
コーディネータ BE ノードがデータをすべてのタブレットのレプリカに配信します。
注意
タブレットはテーブルの論理スライスです。テーブルには複数のタブレットがあり、各タブレットには
replication_numレプリカがあります。テーブル内のタブレットの数は、テーブルのbucket_sizeプロパティによって決まります。 -
データがすべてのタブレットにロードされ保存された後、FE はロードされたデータを可視化します。
-
FE はクライアントにロード成功を返します。
このようなルーチンは、極端なシナリオでもサービスの可用性を保証します。
Write quorum
マルチレプリカテーブルへのデータロードは非常に時間がかかることがあります。ロードパフォーマンスを向上させたい場合、比較的低いデータ可用性を許容できる場合は、テーブルに対して低い書き込みクォーラムを設定できます。書き込みクォーラムとは、書き込み操作が成功と見なされる前に確認が必要なレプリカの最小数を指します。write_quorum プロパティを追加して CREATE TABLE するか、既存のテーブルにこのプロパティを追加することで指定できます。このプロパティは v2.5 からサポートされています。
write_quorum は次の値をサポートします：
MAJORITY: デフォルト値。データレプリカの過半数がロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。ONE: データレプリカのいずれかがロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。ALL: すべてのデータレプリカがロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。
自動レプリカ修復
レプリカは、特定の BE ノードがクラッシュしたり、いくつかのロードタスクが失敗したりすることで失敗することがあります。StarRocks はこれらの失敗したレプリカを自動的に修復します。
tablet_sched_checker_interval_seconds ごとに、デフォルトで 20 秒、FE の Tablet Checker は StarRocks クラスター内のすべてのテーブルのすべてのタブレットレプリカをスキャンし、現在可視のデータのバージョン番号と BE ノードの健康状態を確認してレプリカが健康かどうかを判断します。レプリカの可視バージョンが他のレプリカのバージョンよりも遅れている場合、StarRocks は増分クローンを実行して失敗したレプリカを修復します。BE ノードがハートビートを受信できない場合やクラスターから削除された場合、またはレプリカが増分クローンで修復できないほど遅れている場合、StarRocks は完全なクローンを実行して失われたレプリカを修復します。
修復が必要なタブレットレプリカを検出した後、FE はタブレットスケジューリングタスクを生成し、そのタスクをスケジューリングタスクキューに追加します。FE の Tablet Scheduler はキューからスケジューリングタスクを受け取り、必要なクローンタイプに従って各失敗したレプリカのクローンタスクを作成し、そのタスクを実行する BE ノードに割り当てます。
クローンタスクは本質的に、健康なレプリカを持つソース BE ノードからデータをコピーし、失敗したレプリカを持つ宛先 BE ノードにデータをロードすることです。データバージョンが遅れているレプリカの場合、FE は失敗したレプリカを保存する BE 実行者に増分クローンタスクを割り当て、健康なレプリカを見つけて新しいデータをクローンするためのピア BE ノードを実行者 BE ノードに通知します。レプリカが失われた場合、FE は生存している BE ノードを実行者 BE ノードとして選択し、BE ノードに空のレプリカを作成し、BE ノードに完全なクローンタスクを割り当てます。
クローンタスクの種類に関係なく、実行者 BE ノードは健康なレプリカから物理データファイルを複製し、その後メタデータを適切に更新します。クローンタスクが完了すると、実行者 BE ノードは FE の Tablet Scheduler にタスクの成功を報告します。冗長なタブレットレプリカを削除した後、FE はメタデータを更新し、レプリカ修復の完了を示します。
タブレットの修復中でも、StarRocks はクエリを実行できます。健康なレプリカの数が write_quorum を満たしている限り、StarRocks はテーブルにデータをロードできます。
レプリカの手動修復
手動でのレプリカ修復は次の 2 つのステップで構成されます：
- レプリカのステータスを確認します。
- レプリカの優先度レベルを設定します。
レプリカのステータスを確認する
タブレットのレプリカステータスを確認して、健康でない（失敗した）タブレットを特定します。
-
クラスター内のすべてのタブレットのステータスを確認します。
SHOW PROC '/statistic';例：
mysql> 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: 対応するデータベース内の健康でないタブレットの数を示します。InconsistentTabletNum: レプリカが不一致のタブレットの数を示します。
特定のデータベースで
UnhealthyTabletNumまたはInconsistentTabletNumの値が0でない場合、そのデータベースのDbIdを使用して健康でないタブレットを確認できます。SHOW PROC '/statistic/<DbId>'例：
mysql> SHOW PROC '/statistic/5909381';
+------------------+---------------------+
| UnhealthyTablets | InconsistentTablets |
+------------------+---------------------+
| [40467980] | [] |
+------------------+---------------------+健康でないタブレットの ID は
UnhealthyTabletsフィールドに返されます。 -
特定のテーブルまたはパーティション内のタブレットステータスを確認します。
ADMIN SHOW REPLICA STATUS の WHERE 句を使用して、特定の
STATUSを持つタブレットをフィルタリングできます。ADMIN SHOW REPLICA STATUS FROM <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]
[WHERE STATUS = {'OK'|'DEAD'|'VERSION_ERROR'|'SCHEMA_ERROR'|'MISSING'}]例：
mysql> ADMIN SHOW REPLICA STATUS FROM tbl 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 を使用して、テーブル内のタブレットの詳細をさらに調べることができます。
SHOW TABLET FROM <table_name>例：
mysql> 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 |
+----------+-----------+-----------+------------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+----------+----------+--------+-------------------------+--------------+----------------------+--------------+----------------------+----------------------+----------------------+返された結果には、タブレットのサイズ、行数、バージョン、URL が表示されます。
SHOW TABLET によって返される
Stateフィールドは、タブレットのタスク状態を示し、CLONE、SCHEMA_CHANGE、ROLLUPを含みます。ADMIN SHOW REPLICA DISTRIBUTION を使用して、特定のテーブルまたはパーティションのレプリカ分布を確認し、これらのレプリカが均等に分布しているかどうかを確認できます。
ADMIN SHOW REPLICA DISTRIBUTION FROM <table_name>例：
mysql> 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 ノード上のタブレットレプリカの数とそれに対応する割合が表示されます。
-
特定のタブレットのレプリカステータスを確認します。
前の手順で取得した健康でないタブレットの
TabletIdを使用して、それらのレプリカステータスを調べることができます。SHOW TABLET <TabletId>例：
mysql> 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'; |
+------------------------+-----------+---------------+-----------+----------+----------+-------------+----------+--------+---------------------------------------------------------------------------+返された結果には、タブレットのデータベース、テーブル、パーティション、インデックス (Rollup) に関する詳細情報が表示されます。
DetailCmdフィールドの SQL ステートメントをコピーして、タブレットのレプリカステータスをさらに調べることができます。例：
mysql> 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 Scheduler は、各クローンタスクのタイプに応じて異なる優先度レベルを自動的に割り当てます。
特定のテーブルまたは特定のパーティションのタブレットを最優先で修復したい場合、 ADMIN REPAIR TABLE を使用して手動で VERY_HIGH 優先度レベルを割り当てることができます。
ADMIN REPAIR TABLE <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]
注意
- この SQL ステートメントを実行することは、修復されるタブレットの優先度レベルを変更するヒントを送信するだけです。これらのタブレットが正常に修復されることを保証するものではありません。
- この SQL ステートメントを実行した後でも、Tablet Scheduler はこれらのタブレットに異なる優先度レベルを割り当てる可能性があります。
- Leader FE ノードが変更または再起動されると、この SQL ステートメントが送信したヒントは期限切れになります。
この操作は、 ADMIN CANCEL REPAIR TABLE を使用してキャンセルできます。
ADMIN CANCEL REPAIR TABLE <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]
レプリカのバランシング
StarRocks は、BE ノード間でタブレットを自動的にバランスします。
高負荷ノードから低負荷ノードにタブレットを移動するために、StarRocks はまず低負荷ノードにタブレットのレプリカを作成し、その後高負荷ノード上の対応するレプリカを削除します。クラスター内で異なるタイプの記憶媒体が使用されている場合、StarRocks はすべての BE ノードを記憶媒体タイプに従って分類します。可能な限り、StarRocks は同じ記憶媒体タイプの BE ノード間でタブレットを移動します。同じタブレットのレプリカは異なる BE ノードに保存されます。
BE の負荷
StarRocks は、ClusterLoadStatistics (CLS) を使用してクラスター内の各 BE ノードの負荷統計を表示します。Tablet Scheduler は ClusterLoadStatistics に基づいてレプリカのバランシングをトリガーします。StarRocks は各 BE ノードの ディスク使用率 と レプリカ数 を評価し、それに応じて loadScore を計算します。BE ノードの loadScore が高いほど、そのノードの負荷が高いことを示します。Tablet Scheduler は ClusterLoadStatistics を毎分更新します。
capacityCoefficient と replicaNumCoefficient は、それぞれディスク使用率とレプリカ数の重み係数です。capacityCoefficient と replicaNumCoefficient の合計は 1 です。capacityCoefficient は実際のディスク使用量に応じて動的に調整されます。BE ノードの全体的なディスク使用率が 50% 未満の場合、capacityCoefficient の値は 0.5 です。ディスク使用率が 75% を超える場合、その値は 1 です。この制限は FE の設定項目 capacity_used_percent_high_water を介して設定できます。使用率が 50% から 75% の間の場合、capacityCoefficient は次の式に基づいてスムーズに増加します：
capacityCoefficient= 2 * Disk utilization - 0.5
capacityCoefficient は、ディスク使用量が非常に高い場合に、この BE ノードの loadScore を高くし、システムがこの BE ノードの負荷を最優先で減少させるようにします。
バランシングポリシー
Tablet Scheduler がタブレットをスケジュールするたびに、Load Balancer を通じてバランスを取る候補タブレットとして一定数の健康なタブレットを選択します。次回タブレットをスケジュールする際、Tablet Scheduler はこれらの健康なタブレットをバランスします。
タブレットスケジューリングタスクを確認する
保留中、実行中、および完了したタブレットスケジューリングタスクを確認できます。
-
保留中のタブレットスケジューリングタスクを確認する
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: スケジュール待ちのタブレットの ID。スケジュールされたタスクは 1 つのタブレットに対してのみです。Type: タスクのタイプ。有効な値：REPAIR および BALANCE。Status: タブレットの現在のステータス。例：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';返された結果は、保留中のタスクの結果と同じです。
-
完了したタブレットスケジューリングタスクを確認する
SHOW PROC '/cluster_balance/history_tablets';返された結果は、保留中のタスクの結果と同じです。タスクの
StateがFINISHEDの場合、タスクは正常に完了しています。そうでない場合は、タスク失敗の原因をErrMsgフィールドで確認してください。
リソース制御
StarRocks は、タブレットをある BE ノードから別の BE ノードにクローンすることでタブレットを修復およびバランスしますが、ノードが短時間でこのようなタスクを頻繁に実行すると、BE ノードの I/O 負荷が急増する可能性があります。この状況を避けるために、StarRocks は各 BE ノードのクローンタスクに対して同時実行制限を設定します。リソース制御の最小単位はディスクであり、BE 設定ファイルで指定したデータストレージパス (storage_root_path) です。デフォルトでは、StarRocks は各ディスクに 2 つのスロットを割り当ててタブレット修復タスクを処理します。クローンタスクは、ソース BE ノードと宛先 BE ノードのそれぞれで 1 つのスロットを占有します。BE ノード上のすべてのスロットが占有されている場合、StarRocks はそのノードへのタスクのスケジューリングを停止します。BE ノードのスロット数を増やすには、FE 動的パラメータ tablet_sched_slot_num_per_path の値を増やします。
StarRocks は、タブレットバランシングタスク専用に 2 つのスロットを割り当てて、高負荷の BE ノードがタブレット修復タスクがスロットを占有し続けるためにディスクスペースを解放できない状況を回避します。