レプリカの管理
このトピックでは、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 を追加するか、 ALTER TABLE を使用して既存のテーブルにこのプロパティを追加することで指定できます。このプロパティは v2.5 からサポートされています。
write_quorum は次の値をサポートしています:
MAJORITY: デフォルト値。データレプリカの大多数がロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。ONE: データレプリカのいずれかがロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。ALL: すべてのデータレプリカがロード成功を返すと、StarRocks はロードタスクの成功を返します。それ以外の場合、StarRocks はロードタスクの失敗を返します。
自動レプリカ修復
レプリカは、特定の BE ノードがクラッシュしたり、いくつかのロードタスクが失敗したりすることで失敗することがあります。StarRocks はこれらの失敗したレプリカを自動的に修復します。
tablet_sched_checker_interval_seconds ごとに、デフォルトで 20 秒、FE のタブレットチェッカーが StarRocks クラスター内のすべてのテーブルのすべてのタブレットレプリカをスキャンし、現在可視なデータのバージョン番号と BE ノードの健康状態を確認してレプリカが健康かどうかを判断します。レプリカの可視バージョンが他のレプリカよりも遅れている場合、StarRocks は増分クローンを実行して失敗したレプリカを修復します。BE ノードがハートビートを受信できない場合やクラスターから削除された場合、またはレプリカが増分クローンで修復できないほど遅れている場合、StarRocks は完全なクローンを実行して失われたレプリカを修復します。
修復が必要なタブレットレプリカを検出した後、FE はタブレットスケジューリングタスクを生成し、そのタスクをスケジューリングタスクキューに追加します。FE のタブレットスケジューラはキューからスケジューリングタスクを受け取り、必要なクローンタイプに応じて各失敗したレプリカのクローンタスクを作成し、タスクを実行する BE ノードに割り当てます。
クローンタスクは本質的に、ソース BE ノード（健康なレプリカを持つ）からデータをコピーし、デスティネーション BE ノード（失敗したレプリカを持つ）にデータをロードすることです。データバージョンが遅れているレプリカの場合、FE は失敗したレプリカを保存する BE 実行者に増分クローンタスクを割り当て、どのピア BE ノードから健康なレプリカを見つけて新しいデータをクローンできるかを BE ノードに通知します。レプリカが失われた場合、FE は生存している BE ノードを実行者 BE ノードとして選択し、BE ノードに空のレプリカを作成し、BE ノードに完全なクローンタスクを割り当てます。
クローンタスクの種類に関係なく、実行者 BE ノードは健康なレプリカから物理データファイルを複製し、その後メタデータを適切に更新します。クローンタスクが完了すると、実行者 BE ノードはタスクの成功を FE のタブレットスケジューラに報告します。冗長なタブレットレプリカを削除した後、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 |
+-----------+-----------+---------+-------------+-------------------+-----------------------+------------------+----------------------+---------------+------------+----------+----------+--------+-------+--------------+----------------------+----------+------------------+返された結果には、タブレットのすべてのレプリカが表示されます。
レプリカの優先度レベルを設定
タブレットスケジューラは、各クローンタスクのタイプに応じて異なる優先度レベルを自動的に割り当てます。
特定のテーブルや特定のパーティションのタブレットを最優先で修復したい場合、 ADMIN REPAIR TABLE を使用して手動で VERY_HIGH 優先度レベルを割り当てることができます。
ADMIN REPAIR TABLE <table_name>
[PARTITION (<partition_name_1>[, <partition_name_2>, ...])]
注意
- この SQL 文を実行することは、修復されるタブレットの優先度レベルを変更するヒントを送信するだけです。これらのタブレットが正常に修復されることを保証するものではありません。
- この SQL 文を実行した後でも、タブレットスケジューラはこれらのタブレットに異なる優先度レベルを割り当てることがあります。
- 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 ノードの負荷統計を表示します。タブレットスケジューラは ClusterLoadStatistics に基づいてレプリカのバランシングをトリガーします。StarRocks は、各 BE ノードの ディスク使用率 と レプリカ数 を評価し、それに応じて loadScore を計算します。BE ノードの loadScore が高いほど、そのノードの負荷が高くなります。タブレットスケジューラは 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 ノードの負荷を最優先で減らすようにします。
バランシングポリシー
タブレットスケジューラがタブレットをスケジュールするたびに、Load Balancer を通じてバランスされる候補タブレットとして一定数の健康なタブレットを選択します。次回タブレットをスケジュールする際、タブレットスケジューラはこれらの健康なタブレットをバランスします。
タブレットスケジューリングタスクを確認
保留中、実行中、および完了したタブレットスケジューリングタスクを確認できます。
-
保留中のタブレットスケジューリングタスクを確認
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 はそのノードへのタスクのスケジューリングを停止します。BE ノードのスロット数を増やすには、FE 動的パラメータ tablet_sched_slot_num_per_path の値を増やします。
StarRocks は、タブレットバランシングタスク専用に 2 つのスロットを割り当て、高負荷の BE ノードがタブレット修復タスクがスロットを占有し続けるためにディスクスペースを解放できない状況を回避します。