レプリカの管理
このトピックでは、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
マルチレプリカテーブルへのデータロードは非常に時間がかかることがあります。ロードパフォーマンスを向上させたい場合、そして比較的低いデータ可用性を許容できる場合は、テーブルに対して低い書き込みクォーラムを設定できます。書き込みクォーラムとは、書き込み操作が成功と見なされる前に確認が必要なレプリカの最小数を指します。書き込みクォーラムは、 CREATE TABLE 時にプロパティ write_quorum を追加するか、既存のテーブルにこのプロパティを追加することで指定できます。これは 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 ノードで 1 つのスロットを占有し、デスティネーション BE ノードで 1 つのスロットを占有します。BE ノードのすべてのスロットが占有されている場合、StarRocks はそのノードにタスクをスケジュールするのを停止します。FE 動的パラメータ tablet_sched_slot_num_per_path の値を増やすことで、BE ノードのスロット数を増やすことができます。
StarRocks は、タブレットバランシングタスク専用に 2 つのスロットを割り当てて、高負荷 BE ノードがタブレット修復タスクがスロットを占有し続けるためにディスクスペースを解放できない状況を回避します。