PD スケジューリングのベスト プラクティス
このドキュメントでは、アプリケーションを容易にするために、一般的なシナリオを通じて PD スケジューリングの原則と戦略について詳しく説明します。このドキュメントは、TiDB、TiKV、および PD の基本的な知識があり、次の中心的な概念があることを前提としています。
ノート：
このドキュメントは、最初は TiDB 3.0 を対象としています。一部の機能は以前のバージョン (2.x) ではサポートされていませんが、基本的なメカニズムは類似しており、このドキュメントは参照として引き続き使用できます。
PD スケジューリング ポリシー
このセクションでは、スケジューリング システムに関連する原則とプロセスを紹介します。
スケジューリングプロセス
スケジューリング プロセスには、通常、次の 3 つの手順があります。
情報を収集する
各 TiKV ノードは定期的に 2 種類のハートビートを PD に報告します。
StoreHeartbeat: ディスク容量、使用可能なstorage、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれますRegionHeartbeat: 各リージョンの範囲、ピアの分布、ピアのステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます
PD は、スケジュール決定のためにこの情報を収集して復元します。
オペレータの生成
さまざまなスケジューラーが独自のロジックと要件に基づいてオペレーターを生成しますが、次の考慮事項があります。
- 異常な状態 (切断、ダウン、ビジー、容量不足) のストアにピアを追加しないでください。
- 異常な状態の領域をバランスさせない
- 保留中のピアにリーダーを転送しない
- 引出線を直接削除しないでください
- さまざまなリージョン ピアの物理的な分離を壊さないでください
- ラベル プロパティなどの制約に違反しない
オペレーターの実行
演算子を実行するための一般的な手順は次のとおりです。
生成されたオペレーターは、最初に
OperatorControllerによって管理されるキューに参加します。OperatorController、オペレーターをキューから取り出し、構成に基づいて一定量の同時実行で実行します。このステップでは、各オペレーター ステップを対応する地域リーダーに割り当てます。オペレーターは「終了」または「タイムアウト」としてマークされ、キューから削除されます。
負荷分散
リージョンは、主にbalance-leaderまたはbalance-regionのスケジューラに依存して負荷分散を実現します。両方のスケジューラーはbalance-regionクラスター内のすべてのストアに均等にリージョンを分散することをターゲットbalance-leaderしていますが、別の焦点を当てています。 .
balance-leaderとbalance-region同様のスケジューリング プロセスを共有します。
- リソースの可用性に応じてストアを評価します。
balance-leaderまたはbalance-regionスコアの高い店舗からスコアの低い店舗へリーダーまたはピアを常に移動させます。
ただし、評価方法は異なります。 balance-leader店舗のリーダーに対応するすべての領域サイズの合計を使用しますが、 balance-regionの方法は比較的複雑です。各ノードの特定のstorage容量に応じて、評価方法balance-regionは次のようになります。
- 十分なstorageがある場合のデータ量に基づきます (ノード間のデータ分散のバランスを取るため)。
- storageが不十分な場合に使用可能なstorageに基づいて (異なるノードでstorageの可用性のバランスを取るため)。
- どちらの状況にも当てはまらない場合は、上記の 2 つの要因の加重合計に基づいています。
ノードによってパフォーマンスが異なる場合があるため、ストアごとに負荷分散の重みを設定することもできます。 leader-weightとregion-weight 、リーダーの重みと領域の重みをそれぞれ制御するために使用されます (両方のデフォルトで「1」)。例えば、店舗のleader-weight 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダーの数は他のノードの約 2 倍になります。同様に、ストアのleader-weight 「0.5」に設定すると、ノードのリーダーの数は他のノードの約半分になります。
ホット リージョンのスケジューリング
ホット リージョンのスケジューリングには、 hot-region-schedulerを使用します。 TiDB v3.0 以降、プロセスは次のように実行されます。
ストアから報告された情報に基づいて、特定の期間に特定のしきい値を超える読み取り/書き込みトラフィックを判断して、ホット リージョンをカウントします。
ロード バランシングと同様の方法で、これらのリージョンを再配布します。
ホット ライト リージョンの場合、 hot-region-schedulerリージョン ピアとリーダーの両方の再配布を試みます。ホット リード リージョンの場合、 hot-region-schedulerリージョン リーダーのみを再配布します。
クラスタトポロジの認識
クラスタトポロジの認識により、PD はリージョンのレプリカを可能な限り分散できます。これが、TiKV が高可用性と災害復旧機能を保証する方法です。 PD は、バックグラウンドですべての領域を継続的にスキャンします。 PD は、リージョンの分散が最適ではないことを検出すると、ピアを置き換えてリージョンを再分散する演算子を生成します。
リージョンの分散をチェックするコンポーネントはreplicaCheckerで、無効にできない点を除いてスケジューラに似ています。 location-labelsの構成に基づくreplicaCheckerスケジュール。たとえば、 [zone,rack,host]クラスターの 3 層トポロジーを定義します。 PD は、リージョン ピアを最初に別のゾーンにスケジュールしようとします。ゾーンが不十分な場合は別のラックにスケジュールしようとします (たとえば、3 つのレプリカに対して 2 つのゾーン)。ラックが不十分な場合は別のホストにスケジュールしようとします。
スケールダウンと障害復旧
スケールダウンとは、ストアをオフラインにし、コマンドを使用して「オフライン」としてマークするプロセスを指します。 PD は、スケジューリングによって、オフライン ノード上のリージョンを他のノードに複製します。障害回復は、ストアに障害が発生して回復できない場合に適用されます。この場合、対応するストアにピアが分散されているリージョンはレプリカを失う可能性があり、他のノードで PD を補充する必要があります。
スケールダウンと障害回復のプロセスは基本的に同じです。 replicaChecker 、異常な状態のリージョン ピアを検出し、異常なピアを正常なストアの新しいピアに置き換える演算子を生成します。
リージョンのマージ
リージョン結合とは、隣接する小さな領域を結合するプロセスを指します。これは、データの削除後に多数の小さなリージョンまたは空のリージョンによって不要なリソースが消費されるのを回避するのに役立ちます。リージョンのマージはmergeCheckerによって実行され、 replicaCheckerと同様の方法で処理されます。PD はバックグラウンドですべての領域を継続的にスキャンし、連続する小さな領域が見つかったときに演算子を生成します。
具体的には、新しく分割されたリージョンがsplit-merge-intervalの値 (デフォルトでは1h ) を超えて存在する場合、次の条件が同時に発生した場合、このリージョンはリージョンのマージ スケジューリングをトリガーします。
このリージョンのサイズは、
max-merge-region-sizeの値よりも小さい (デフォルトで 20 MiB)このリージョンのキーの数は、値
max-merge-region-keysよりも小さくなっています (デフォルトでは 200,000)。
クエリのスケジューリング ステータス
メトリック、pd-ctl、およびログを使用して、スケジューリング システムのステータスを確認できます。このセクションでは、metrics と pd-ctl のメソッドを簡単に紹介します。詳細はPD モニタリング メトリックとPD Controlを参照してください。
オペレーターの状態
Grafana PD/Operatorページには、オペレーターに関するメトリックが表示されます。
- スケジュール担当者作成：担当者作成情報
- オペレーター終了時間：各オペレーターの実行時間
- オペレーター・ステップ所要時間: オペレーター・ステップの実行時間
次のコマンドで pd-ctl を使用して演算子をクエリできます。
operator show: 現在のスケジューリング タスクで生成されたすべてのオペレータを照会します。operator show [admin | leader | region]: タイプごとに演算子を照会します
残高状況
Grafana PD/ 統計 - Balanceページには、負荷分散に関するメトリックが表示されます。
- 店舗リーダー・地域スコア：各店舗のスコア
- 店舗のリーダー/地域数: 各店舗のリーダー/地域の数
- 利用可能なストア: 各ストアで利用可能なstorage
pd-ctl のストア コマンドを使用して、各ストアの残高ステータスを照会できます。
ホットリージョンのステータス
Grafana PD/ 統計 - hotspotページには、ホット リージョンに関するメトリックが表示されます。
- ホット ライト リージョンのリーダー/ピア ディストリビューション: ホット ライト リージョンのリーダー/ピア ディストリビューション
- ホットリード領域のリーダー分布: ホットリード領域のリーダー分布
次のコマンドで 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: 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を設定して一時的に無効にすることができます。 - スケジューリング プロセスが遅すぎます。オペレーターのステップ期間メトリックをチェックして、原因を確認できます。一般に、スナップショットの送受信を伴わないステップ (
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の制限を緩めることを検討できます。 - 他のスケジューリング タスクが同時に実行され、システム内のリソースが競合しています。 リーダー/リージョンが均等に分散されていないの解決策を参照できます。
- 1 つのノードをオフラインにすると、処理対象のリージョン リーダーの数 (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を設定できます (この構成項目のデフォルト値は、v5.3.0 以降のバージョンの TiDB では10msです)。これにより、リージョンのスキャンが高速化されますが、CPU の消費が増えます。多くのテーブルが作成されてから空にされました (切り捨てられたテーブルを含む)。分割テーブル属性が有効になっている場合、これらの空のリージョンはマージできません。この属性を無効にするには、次のパラメーターを調整します。
TiKV:
split-region-on-table～falseを設定します。パラメータを動的に変更することはできません。PD: PD Controlを使用して、クラスターの状況に必要なパラメーターを設定します。
- クラスターに TiDB インスタンスがなく、値
key-typeがrawまたはtxnに設定されているとします。この場合、 PD は、enable-cross-table-merge settingの値に関係なく、テーブル全体でリージョンをマージできます。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構成が有効にならないのはなぜですか?を参照してください。ノート：
Placement Rules を有効にした後、値
key-type適切に切り替えて、デコードの失敗を回避してください。- クラスターに TiDB インスタンスがなく、値
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 ノードは低速としてマークされます。 evict-slow-store-schedulerを追加すると、低速ノードを検出してスケジュールできます。 TiKV が 1 つだけ遅いと検出され、遅いスコアが上限 (デフォルトでは 100) に達した場合、このノードのリーダーは削除されます ( evict-leader-schedulerの効果と同様)。