PD スケジュールのベスト プラクティス

このドキュメントでは、アプリケーションを容易にするために、一般的なシナリオを通じて PD スケジューリングの原則と戦略について詳しく説明します。このドキュメントでは、TiDB、TiKV、PD について、次のコア コンセプトに関する基本的な知識があることを前提としています。

• リーダー/フォロワー/学習者
• オペレーター
• 演算子ステップ
• 保留中/ダウン
• 地域/ピア/ Raftグループ
• 地域分割
• スケジューラ
• 店

注記：

このドキュメントは、当初は TiDB 3.0 を対象としています。一部の機能は以前のバージョン (2.x) ではサポートされていませんが、基礎となるメカニズムは同様であるため、このドキュメントは引き続きリファレンスとして使用できます。

PDスケジュールポリシー

このセクションでは、スケジューリング システムに関連する原則とプロセスについて説明します。

スケジュール作成プロセス

スケジュール設定プロセスには通常、次の 3 つのステップがあります。

1. 情報を収集する

   各 TiKV ノードは、定期的に 2 種類のハートビートを PD に報告します。

   • StoreHeartbeat : ディスク容量、使用可能なstorage、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。
   • RegionHeartbeat : 各リージョンの範囲、ピア分布、ピアステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます。

   PD はスケジュール決定のためにこの情報を収集し、復元します。

2. 演算子を生成する

   さまざまなスケジューラは、次の点を考慮して、独自のロジックと要件に基づいて演算子を生成します。

   • 異常な状態（切断、ダウン、ビジー、容量不足）のピアをストアに追加しないでください。
   • 異常な状態の領域のバランスをとらない
   • リーダーを保留中のピアに転送しないでください
   • リーダーを直接削除しないでください
   • さまざまなリージョンピアの物理的な分離を破壊しない
   • ラベルプロパティなどの制約に違反しない

3. 実行演算子

   演算子を実行するための一般的な手順は次のとおりです。

   1. 生成された演算子は、まずOperatorControllerによって管理されるキューに参加します。

   2. OperatorControllerキューから演算子を取り出し、構成に基づいて一定量の同時実行で実行します。このステップでは、各演算子ステップを対応するリージョン リーダーに割り当てます。

   3. オペレータは「終了」または「タイムアウト」としてマークされ、キューから削除されます。

負荷分散

リージョンは、負荷分散を実現するために主にbalance-leaderおよびbalance-regionスケジューラに依存しています。両方のスケジューラは、クラスター内のすべてのストアにリージョンを均等に分散することを目標としていますが、焦点は異なります。5 balance-leaderリージョン リーダーと連携して着信クライアント要求のバランスを取りますが、 balance-region各リージョン ピアと連携してstorageの負荷を再分散し、storage領域不足などの例外を回避します。

balance-leaderとbalance-region同様のスケジュール プロセスを共有します。

1. リソースの可用性に応じて店舗を評価します。
2. balance-leaderまたはbalance-region高スコアの店舗から低スコアの店舗へ、リーダーまたは同僚を継続的に異動させます。

ただし、評価方法は異なります。1 balance-leader 、ストア内のリーダーに対応するすべての領域サイズの合計を使用しますが、 balance-regionの方法は比較的複雑です。各ノードの特定のstorage容量に応じて、 balance-regionの評価方法は次のようになります。

• 十分なstorageがある場合のデータ量に基づいて（ノード間のデータ分散のバランスをとるため）。
• storageが不足している場合は、使用可能なstorageに基づいて割り当てます (異なるノード上のstorageの可用性のバランスをとるため)。
• どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。

ノードによってパフォーマンスが異なる場合があるため、ストアごとに負荷分散の重みを設定することもできます。1 とleader-weight region-weight 、それぞれリーダーの重みとリージョンの重みを制御するために使用されます (どちらもデフォルトで「1」)。たとえば、ストアのleader-weightが「2」に設定されている場合、スケジューリングが安定した後、ノード上のリーダーの数は他のノードの約 2 倍になります。同様に、ストアのleader-weightが「0.5」に設定されている場合、ノード上のリーダーの数は他のノードの約半分になります。

ホットリージョンのスケジュール

ホット リージョンのスケジュールにはhot-region-scheduler使用します。TiDB v3.0 以降では、プロセスは次のように実行されます。

1. ストアから報告された情報に基づいて、一定期間に特定のしきい値を超える読み取り/書き込みトラフィックを判別し、ホット領域をカウントします。

2. 負荷分散と同様の方法でこれらの領域を再配布します。

ホット書き込み領域の場合、 hot-region-scheduler領域ピアとリーダーの両方の再配布を試行します。ホット読み取り領域の場合、 hot-region-scheduler領域リーダーのみを再配布します。

クラスタトポロジの認識

クラスタトポロジの認識により、PD はリージョンのレプリカを可能な限り分散できます。これにより、TiKV は高可用性と災害復旧機能を確保します。PD はバックグラウンドですべてのリージョンを継続的にスキャンします。PD はリージョンの分散が最適ではないと判断した場合、ピアを置き換えてリージョンを再分散するオペレーターを生成します。

リージョン分散をチェックするコンポーネントはreplicaCheckerです。これは、無効にできないことを除いてスケジューラに似ています。 replicaChecker location-labelsの構成に基づいてスケジュールします。たとえば、 [zone,rack,host]クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを別のゾーンにスケジュールしようとします。ゾーンが不十分な場合は別のラックにスケジュールしようとします (たとえば、3 つのレプリカに対して 2 つのゾーン)。ラックが不十分な場合は別のホストにスケジュールしようとします。

スケールダウンと障害回復

スケールダウンとは、コマンドを使用してストアをオフラインにし、「オフライン」としてマークするプロセスを指します。PD は、スケジュールに従って、オフライン ノード上の領域を他のノードに複製します。障害回復は、ストアが失敗して回復できない場合に適用されます。この場合、対応するストアに分散されたピアを持つ領域でレプリカが失われる可能性があり、PD が他のノードで補充する必要があります。

スケールダウンと障害回復のプロセスは基本的に同じです。1 replicaChecker異常な状態にあるリージョン ピアを見つけ、異常なピアを正常なストア上の新しいピアに置き換える演算子を生成します。

リージョンの統合

リージョンマージとは、隣接する小さな領域をマージするプロセスを指します。これは、データ削除後に多数の小さな領域や空の領域によって不必要なリソースが消費されるのを防ぐのに役立ちます。リージョンマージはmergeCheckerによって実行され、 replicaCheckerと同様の方法で処理されます。PD はバックグラウンドですべての領域を継続的にスキャンし、連続した小さな領域が見つかったときに演算子を生成します。

具体的には、新しく分割されたリージョンがsplit-merge-interval (デフォルトでは1h ) を超える値で存在する場合、次の条件が同時に発生すると、このリージョンはリージョンのマージ スケジュールをトリガーします。

• このリージョンのサイズはmax-merge-region-sizeの値より小さいです (デフォルトでは 20 MiB)

• このリージョン内のキーの数は、値max-merge-region-keys (デフォルトでは 200,000) より小さくなります。

クエリのスケジュールステータス

スケジューリング システムの状態は、メトリクス、pd-ctl、ログを通じて確認できます。このセクションでは、メトリクスと pd-ctl の方法について簡単に説明します。詳細については、 PD モニタリング メトリックとPD Controlを参照してください。

オペレータステータス

Grafana PD/Operatorページには、次のようなオペレーターに関するメトリックが表示されます。

• スケジュールオペレータ作成:オペレータ作成情報
• オペレータ終了時間: 各オペレータが消費した実行時間
• オペレータステップの所要時間: オペレータステップで消費される実行時間

次のコマンドを使用して、pd-ctl を使用して演算子を照会できます。

• operator show : 現在のスケジュールタスクで生成されたすべての演算子を照会します
• operator show [admin | leader | region] : 演算子をタイプ別に照会する

残高ステータス

Grafana PD/統計- バランスページには、次のような負荷分散に関するメトリックが表示されます。

• 店舗リーダー/地域スコア: 各店舗のスコア
• 店舗リーダー/地域数: 各店舗のリーダー/地域の数
• 利用可能なストア: 各ストアで利用可能なstorage

pd-ctl のストア コマンドを使用して、各ストアの残高ステータスを照会できます。

ホットリージョンステータス

Grafana PD/統計- ホットスポットページには、次のようなホット リージョンに関するメトリックが表示されます。

• ホット書き込み領域のリーダー/ピア分布: ホット書き込み領域におけるリーダー/ピア分布
• ホットリード領域のリーダー分布: ホットリード領域におけるリーダー分布

次のコマンドで pd-ctl を使用してホット リージョンのステータスを照会することもできます。

• hot read : ホットリード領域を照会する
• hot write : ホット書き込み領域を照会する
• hot store : 店舗別のホットリージョンの分布を照会する
• region topread [limit] : 読み取りトラフィックが最も多い領域を照会します
• region topwrite [limit] : 書き込みトラフィックが最も多い領域を照会する

リージョンの健康

Grafana PD/クラスタ/リージョンのヘルスパネルには、異常な状態にあるリージョンに関するメトリックが表示されます。

pd-ctl とリージョン チェック コマンドを使用して、異常状態にあるリージョンのリストを照会できます。

• region check miss-peer : 十分なピアがない領域を照会する
• region check extra-peer : 追加のピアを持つ領域を照会する
• region check down-peer : ダウンしているピアがある領域を照会する
• region check pending-peer : 保留中のピアがある領域を照会する

スケジュール戦略の制御

pd-ctl を使用すると、次の 3 つの側面からスケジューリング戦略を調整できます。詳細については、 PD Controlを参照してください。

スケジューラを手動で追加/削除する

PD は、pd-ctl を介してスケジューラを直接動的に追加および削除することをサポートしています。例:

• scheduler show : システムで現在実行中のスケジューラを表示します
• scheduler remove balance-leader-scheduler : バランスリーダースケジューラを削除（無効化）する
• scheduler add evict-leader-scheduler 1 : ストア 1 のすべてのリーダーを削除するスケジューラを追加します。

オペレータを手動で追加/削除する

PD は、pd-ctl を介して演算子を直接追加または削除することもサポートしています。例:

• operator add add-peer 2 5 : ストア5のリージョン2にピアを追加します
• operator add transfer-leader 2 5 :リージョン2のリーダーをストア5に移行します
• operator add split-region 2 :リージョン2を均等なサイズで2つの領域に分割します
• operator remove 2 :リージョン2で現在保留中の演算子を削除します

スケジュールパラメータを調整する

pd-ctl のconfig showコマンドを使用してスケジュール設定を確認し、 config set {key} {value}使用して値を調整できます。一般的な調整は次のとおりです。

• leader-schedule-limit : 転送リーダーのスケジュールの同時実行を制御する
• region-schedule-limit : ピアスケジューリングの追加/削除の同時実行を制御する
• enable-replace-offline-replica : ノードをオフラインにするスケジュールを有効にするかどうかを決定します
• enable-location-replacement : 領域の分離レベルを処理するスケジュールを有効にするかどうかを決定します
• max-snapshot-count : 各ストアのスナップショットの送受信の最大同時実行数を制御します

一般的なシナリオでのPDスケジュール

このセクションでは、いくつかの一般的なシナリオを通じて PD スケジューリング戦略のベスト プラクティスについて説明します。

リーダー/地域が均等に分布していない

PD の評価メカニズムでは、異なるストアのリーダー数とリージョン数では負荷分散状態を完全に反映できないと判断されます。そのため、TiKV の実際の負荷やstorage使用量から負荷の不均衡があるかどうかを確認する必要があります。

リーダー/地域が均等に分散されていないことを確認したら、さまざまなストアの評価を確認する必要があります。

異なる店舗のスコアが近い場合、PD はリーダー/地域が均等に分散されていると誤って認識していることを意味します。考えられる理由は次のとおりです。

• 負荷の不均衡を引き起こすホット領域があります。この場合は、 ホットリージョンのスケジュールに基づいてさらに分析する必要があります。
• 空の領域や小さな領域が多数あるため、各ストアのリーダーの数に大きな差が生じ、 Raftストアに高い圧力がかかります。これは、 地域統合スケジュールのタイミングです。
• ハードウェアおよびソフトウェア環境は店舗によって異なります。リーダー/リージョンの配分を制御するには、 負荷分散を参照してleader-weightとregion-weightの値を調整します。
• その他の不明な理由。それでも、 leader-weightとregion-weightの値を調整して、リーダー/リージョンの分布を制御することができます。

異なるストアの評価に大きな違いがある場合は、オペレータの生成と実行に特に重点を置いて、オペレータ関連のメトリックを調べる必要があります。主な状況は 2 つあります。

• オペレータが正常に生成されているにもかかわらず、スケジュール処理が遅い場合は、次のことが考えられます。

  • デフォルトでは、負荷分散の目的でスケジューリング速度が制限されています。 leader-schedule-limitまたはregion-schedule-limit 、通常のサービスに大きな影響を与えることなく、より大きな値に調整できます。 また、 max-pending-peer-countとmax-snapshot-countで指定された制限を適切に緩和することもできます。
  • 他のスケジューリング タスクが同時に実行されているため、バランシングが遅くなります。この場合、バランシングが他のスケジューリング タスクよりも優先されるのであれば、他のタスクを停止するか、その速度を制限することができます。たとえば、バランシングの進行中に一部のノードをオフラインにすると、両方の操作でregion-schedule-limitのクォータが消費されます。この場合、ノードを削除するスケジューラの速度を制限するか、単にenable-replace-offline-replica = falseに設定して一時的に無効にすることができます。
  • スケジューリング プロセスが遅すぎます。原因を確認するには、Operator ステップの所要時間メトリックをチェックします。通常、スナップショットの送受信を伴わないステップ ( TransferLeader 、 RemovePeer 、 PromoteLearnerなど) は数ミリ秒で完了しますが、スナップショットを伴うステップ ( AddLearnerやAddPeerなど) は数十秒で完了することが予想されます。所要時間が明らかに長すぎる場合は、TiKV の高負荷またはネットワークのボトルネックが原因である可能性があり、具体的な分析が必要です。

• PD は対応するバランシング スケジューラを生成できません。考えられる理由は次のとおりです。

  • スケジューラがアクティブ化されていません。たとえば、対応するスケジューラが削除されているか、その制限が「0」に設定されています。
  • その他の制約。たとえば、システム内のevict-leader-schedulerにより、リーダーが対応するストアに移行できなくなります。または、ラベル プロパティが設定されているため、一部のストアがリーダーを拒否します。
  • クラスター トポロジからの制限。たとえば、3 つのデータ センターにまたがる 3 つのレプリカのクラスターでは、レプリカの分離により、各リージョンの 3 つのレプリカが異なるデータ センターに分散されます。これらのデータ センター間でストアの数が異なる場合、スケジュールは各データ センター内でのみバランスの取れた状態に到達できますが、グローバルにはバランスが取れません。

ノードをオフラインにするのは遅い

このシナリオでは、関連するメトリックを通じて演算子の生成と実行を調べる必要があります。

オペレータは正常に生成されたが、スケジュール処理が遅い場合、考えられる理由は次のとおりです。

• スケジュール速度はデフォルトで制限されています。 leader-schedule-limitまたはreplica-schedule-limitより大きな値に調整できます。同様に、 max-pending-peer-countとmax-snapshot-countの制限を緩めることも検討できます。
• 他のスケジュール タスクが同時に実行され、システム内のリソースを奪い合っています。 リーダー/地域が均等に分布していないの解決策を参照してください。
• 単一ノードをオフラインにすると、削除するノードに処理対象のリージョンリーダーの数（レプリカ 3 台の構成では約 1/3）が分散されます。そのため、この単一ノードによるスナップショットの生成速度によって速度が制限されます。リーダーの移行に手動でevict-leader-scheduler追加することで、速度を上げることができます。

対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。

• オペレータが停止しているか、 replica-schedule-limit "0" に設定されます。
• リージョン移行に適したノードがありません。たとえば、(同じラベルの) 交換ノードの使用可能な容量サイズが 20% 未満の場合、PD はそのノードのstorageが不足しないようにスケジュールを停止します。このような場合は、スペースを解放するためにノードを追加するか、一部のデータを削除する必要があります。

ノードをオンラインにするのは遅い

現在、ノードをオンラインにすることは、バランス リージョン メカニズムを通じてスケジュールされます。トラブルシューティングについては、 リーダー/地域が均等に分布していないを参照してください。

暑い地域は均等に分布していない

ホット リージョンのスケジュールの問題は、通常、次のカテゴリに分類されます。

• ホット領域は PD メトリックを介して観察できますが、スケジュール速度が追いつかず、ホット領域を時間内に再分配できません。

  解決策: hot-region-schedule-limitより大きな値に調整し、他のスケジューラの制限クォータを減らして、ホット リージョンのスケジューリングを高速化します。または、 hot-region-cache-hits-threshold小さな値に調整して、PD をトラフィックの変化に対してより敏感にすることもできます。

• 単一の領域に形成されたホットスポット。たとえば、小さなテーブルが大量のリクエストによって集中的にスキャンされます。これは PD メトリックからも検出できます。実際には単一のホットスポットを分散することはできないため、このような領域を分割するには、 split-region演算子を手動で追加する必要があります。

• TiKV 関連のメトリックから、一部のノードの負荷が他のノードの負荷よりも大幅に高く、それがシステム全体のボトルネックになっています。現在、PD はトラフィック分析のみでホットスポットをカウントしているため、特定のシナリオでは PD がホットスポットを識別できない可能性があります。たとえば、一部の領域でポイント検索要求が集中している場合、トラフィックで検出するのは明らかではないかもしれませんが、それでも高い QPS が主要なモジュールでボトルネックを引き起こす可能性があります。

  解決策: まず、特定のビジネスに基づいてホット リージョンが形成されるテーブルを見つけます。次に、 scatter-range-schedulerスケジューラを追加して、このテーブルのすべてのリージョンが均等に分散されるようにします。TiDB は、この操作を簡素化するために HTTP API でインターフェイスも提供しています。詳細については、 TiDB HTTP APIを参照してください。

リージョンの統合が遅い

低速スケジューリングと同様に、リージョン マージの速度はmerge-schedule-limitとregion-schedule-limitの構成によって制限されているか、リージョン マージ スケジューラが他のスケジューラと競合している可能性があります。具体的な解決策は次のとおりです。

• メトリクスからシステム内に多数の空き領域があることがわかっている場合は、 max-merge-region-sizeとmax-merge-region-keysを小さい値に調整してマージを高速化できます。これは、マージ プロセスにレプリカの移行が含まれるため、マージする領域が小さいほどマージが高速になるためです。マージ オペレーターがすでに急速に生成されている場合は、プロセスをさらに高速化するために、 patrol-region-intervalを10msに設定できます (この構成項目のデフォルト値は、TiDB の v5.3.0 以降のバージョンでは10msです)。これにより、CPU 消費量が増える代わりに、領域スキャンが高速化されます。

• 多数のテーブルが作成され、その後空になりました (切り捨てられたテーブルを含む)。分割テーブル属性が有効になっている場合、これらの空の領域を結合することはできません。次のパラメータを調整して、この属性を無効にすることができます。

  • TiKV: split-region-on-table 〜 falseに設定します。パラメータを動的に変更することはできません。

  • PD: PD Controlを使用して、クラスターの状況に必要なパラメータを設定します。

    • クラスターに TiDB インスタンスがなく、 key-typeの値がrawまたはtxnに設定されているとします。この場合、 enable-cross-table-merge settingの値に関係なく、PD はテーブル間でリージョンをマージできます。 key-typeパラメータは動的に変更できます。

    config set key-type txn
    

    • クラスターに TiDB インスタンスがあり、 key-typeの値がtableに設定されているとします。この場合、 enable-cross-table-mergeの値がtrueに設定されている場合にのみ、PD はテーブル間でリージョンをマージできます。 key-typeパラメータは動的に変更できます。

    config set enable-cross-table-merge true
    

    変更が有効にならない場合は、 FAQ - TiKV/PD 用に変更されたtoml構成が有効にならないのはなぜですか?を参照してください。

    注記：

    配置ルールを有効にした後、デコードの失敗を回避するためにkey-typeの値を適切に切り替えます。

v3.0.4 および v2.1.16 以前では、特定の状況 (ほとんどの場合、テーブルを削除した後に発生) で領域のapproximate_keysが不正確になり、キーの数がmax-merge-region-keysの制約に違反します。この問題を回避するには、 max-merge-region-keysより大きな値に調整します。

TiKVノードのトラブルシューティング

TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30 分後 (構成項目max-store-down-timeでカスタマイズ可能) にダウン状態に設定し、関係するリージョンのレプリカを再調整します。

実際には、ノード障害が回復不可能と判断された場合は、すぐにオフラインにすることができます。これにより、PD はすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。対照的に、ノードが回復可能と判断されても、30 分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの無駄を避けるために、一時的にmax-store-down-timeより大きな値に調整することができます。

TiDB v5.2.0 では、TiKV に低速 TiKV ノード検出のメカニズムが導入されています。このメカニズムは、TiKV 内のリクエストをサンプリングすることで、1 ～ 100 の範囲のスコアを算出します。スコアが 80 以上の TiKV ノードは低速としてマークされます。1 evict-slow-store-scheduler追加して、低速ノードを検出してスケジュールすることができます。低速として検出された TiKV が 1 つだけで、低速スコアが制限 (デフォルトでは 80) に達した場合、このノードのLeaderは排除されます ( evict-leader-schedulerの効果と同様)。

注記：

Leaderの排除は、 PD が TiKV の低速ノードにスケジュール要求を送信し、TiKV が受信したスケジュール要求を順番に実行することで実現されます。低速 I/Oなどの要因により、低速ノードでは要求が蓄積され、一部のリーダーは遅延要求が処理されるまで待機してからLeaderの排除要求を処理することがあります。これにより、Leaderの排除にかかる時間が全体的に長くなります。したがって、 evict-slow-store-schedulerを有効にする場合は、この状況を緩和するためにstore-io-pool-size有効にすることをお勧めします。