TiDB スケジューリング

配置Driver（ PD ）はTiDBクラスタ内のマネージャとして機能し、クラスタ内のリージョンのスケジュールも行います。この記事では、PDスケジューリングコンポーネントの設計とコアコンセプトを紹介します。

スケジュール状況

TiKV は、TiDB で使用される分散キー値storageエンジンです。TiKV では、データはリージョンとして編成され、複数のストアに複製されます。すべてのレプリカで、リーダーが読み取りと書き込みを担当し、フォロワーがリーダーからのRaftログの複製を担当します。

ここで、次の状況について考えてみましょう。

storageスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。
複数のデータセンタートポロジの場合、1 つのデータセンターに障害が発生すると、すべてのリージョンで 1 つのレプリカのみが失敗します。
新しい TiKV ストアが追加されると、そのストアにデータを再バランスすることができます。
TiKV ストアに障害が発生した場合、PD は次の点を考慮する必要があります。
- 障害が発生したストアの回復時間。
  - 短い場合（たとえば、サービスが再起動された場合）、スケジュールが必要かどうか。
  - 長時間にわたる場合（例えば、ディスク障害が発生してデータが失われる場合）、どのようにスケジュールを立てるか。
- すべてのリージョンのレプリカ。
  - 一部のリージョンでレプリカの数が足りない場合、PD はそれらを完了する必要があります。
  - レプリカの数が予想より多い場合 (たとえば、障害が発生したストアが回復後にクラスターに再参加する場合)、PD はそれらを削除する必要があります。
読み取り/書き込み操作はリーダー上で実行されますが、少数の個別のストアにのみ分散することはできません。
すべてのリージョンがホットなわけではないので、すべての TiKV ストアの負荷をバランスさせる必要があります。
リージョンのバランスが取れている場合、データ転送には多くのネットワーク/ディスクトラフィックと CPU 時間が消費され、オンラインサービスに影響を与える可能性があります。

これらの状況は同時に発生する可能性があり、解決が難しくなります。また、システム全体が動的に変化するため、クラスターに関するすべての情報を収集し、クラスターを調整するスケジューラーが必要です。そこで、PD が TiDB クラスターに導入されました。

スケジュール要件

上記の状況は、次の 2 つのタイプに分類できます。

分散型で可用性の高いstorageシステムは、次の要件を満たす必要があります。
- 適切な数のレプリカ。
- レプリカは、さまざまなトポロジに応じて異なるマシンに分散する必要があります。
- クラスターは、TiKV ピアの障害からの自動災害復旧を実行できます。
優れた分散システムには、次のような最適化が必要です。
- すべてのリージョンリーダーは店舗に均等に分散されます。
- すべての TiKV ピアのストレージ容量がバランスされています。
- ホットスポットはバランスが取れています。
- オンラインサービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。
- メンテナーはピアを手動でオンライン/オフラインにすることができます。

最初のタイプの要件が満たされると、システムは障害を許容できるようになります。2 番目のタイプの要件が満たされると、リソースがより効率的に使用され、システムのスケーラビリティが向上します。

目標を達成するには、PD はまず、ピアの状態、 Raftグループに関する情報、ピアへのアクセスの統計などの情報を収集する必要があります。次に、PD がこれらの情報と戦略からスケジューリングプランを作成できるように、PD にいくつかの戦略を指定する必要があります。最後に、PD はいくつかの演算子を TiKV ピアに配布して、スケジューリングプランを完成させます。

基本的なスケジューリング演算子

すべてのスケジュールプランには、次の 3 つの基本演算子が含まれています。

新しいレプリカを追加する
レプリカを削除する
Raftグループ内のレプリカ間でリージョンリーダーを転送する

これらはRemoveReplica RaftコマンドAddReplica 、およびTransferLeaderによって実装されます。

情報収集

スケジューリングは情報収集に基づいています。つまり、PD スケジューリングコンポーネントは、すべての TiKV ピアとすべてのリージョンの状態を把握する必要があります。TiKV ピアは、次の情報を PD に報告します。

各 TiKV ピアによって報告される状態情報:
各 TiKV ピアは、定期的に PD にハートビートを送信します。PD はストアが稼働しているかどうかを確認するだけでなく、ハートビートメッセージでStoreState収集します。3 にはStoreStateが含まれます。
- ディスク容量合計
- 使用可能なディスク容量
- 地域の数
- データの読み取り/書き込み速度
- 送受信されるスナップショットの数（スナップショットを通じてレプリカ間でデータが複製される可能性があります）
- 店舗が混雑しているかどうか
- ラベル（トポロジーの認識参照）
PD コントロールを使用すると、TiKV ストアのステータス (稼働中、切断、オフライン、ダウン、またはトゥームストーン) を確認できます。以下は、すべてのステータスとその関係の説明です。
- 上: TiKVストアが稼働中です。
- 切断: PD と TiKV ストア間のハートビートメッセージが 20 秒以上失われます。失われた期間がmax-store-down-timeで指定された時間を超えると、ステータス「切断」が「ダウン」に変わります。
- ダウン: PD と TiKV ストア間のハートビートメッセージがmax-store-down-time以上 (デフォルトでは 30 分) 失われています。この状態では、TiKV ストアは、存続しているストアで各リージョンのレプリカの補充を開始します。
- オフライン: TiKV ストアは、 PD Controlを通じて手動でオフラインにされます。これは、ストアがオフラインになるための中間ステータスにすぎません。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の「稼働中」ストアに移動します。2 とregion_count ( PD Controlを通じて取得) の両方がleader_count 0示している場合、ストアステータスは「オフライン」から「廃棄」に変わります。「オフライン」ステータスでは、ストアサービスまたはストアが配置されている物理サーバーを無効にしないでください。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲットストアがない場合 (クラスター内にレプリカを保持するのにストアが不十分な場合など)、ストアは常に「オフライン」ステータスになります。
- トゥームストーン: TiKV ストアは完全にオフラインです。この状態では、 remove-tombstoneインターフェイスを使用して TiKV を安全にクリーンアップできます。
リージョンリーダーから報告された情報:
各リージョンリーダーは、定期的に PD にハートビートを送信して、次の情報を報告しますRegionState 。
- リーダー自身の立場
- 他のレプリカの位置
- オフラインレプリカの数
- データの読み取り/書き込み速度

PD は 2 種類のハートビートによってクラスター情報を収集し、それに基づいて決定を下します。

さらに、PD は拡張されたインターフェースからより多くの情報を取得して、より正確な決定を下すことができます。たとえば、ストアのハートビートが壊れている場合、PD はピアが一時的に停止しているのか、永久に停止しているのかを知ることができません。しばらく待機し (デフォルトでは 30 分)、それでもハートビートを受信しない場合はストアをオフラインとして扱います。次に、PD はストアのすべての領域を他のストアに分散します。

しかし、ストアがメンテナーによって手動でオフラインに設定されることもあります。メンテナーは PD 制御インターフェースを使用して PD にこれを通知できます。その後、PD はすべての領域を即座にバランスさせることができます。

スケジュール戦略

情報を収集した後、PD はスケジュール計画を立てるためのいくつかの戦略を必要とします。

戦略1:リージョンのレプリカの数は正確である必要があります

PD は、リージョンリーダーのハートビートから、リージョンのレプリカ数が正しくないことを知ることができます。その場合、PD はレプリカを追加/削除してレプリカ数を調整できます。レプリカ数が正しくない理由としては、次のことが考えられます。

ストア障害のため、一部のリージョンのレプリカ数が予想よりも少なくなっています。
障害後のストアのリカバリのため、一部のリージョンのレプリカ数が予想より多くなる場合があります。
max-replicasが変更されました。

戦略2:リージョンのレプリカは異なる位置に配置する必要あり

ここで、「位置」は「マシン」とは異なることに注意してください。通常、PD は、ピアの障害によって複数のレプリカが失われるのを回避するために、リージョンのレプリカが同じピアにないことのみを確認できます。ただし、本番では、次の要件がある場合があります。

複数の TiKV ピアが 1 台のマシン上に存在します。
TiKV ピアは複数のラック上にあり、ラックに障害が発生してもシステムは利用可能であると予想されます。
TiKV ピアは複数のデータセンターにあり、データセンターに障害が発生した場合でもシステムは利用可能であると予想されます。

これらの要件の鍵となるのは、ピアが同じ「位置」を持つことができることです。これは、障害許容の最小単位です。リージョンのレプリカは 1 つの単位にあってはなりません。したがって、TiKV ピアにラベル設定し、PD に場所ラベルを設定して、位置のマーク付けに使用するラベルを指定できます。

戦略3: レプリカは店舗間でバランスをとる必要がある

リージョンレプリカのサイズ制限は固定されているため、ストア間でレプリカのバランスを保つことは、データサイズのバランスを保つのに役立ちます。

戦略4: リーダーは店舗間でバランスを取る必要がある

読み取りおよび書き込み操作はRaftプロトコルに従ってリーダー上で実行されるため、PD はリーダーを複数のピアではなくクラスター全体に分散する必要があります。

戦略5: 店舗間でホットスポットのバランスをとる必要がある

PD は、ストアハートビートとリージョンハートビートからホットスポットを検出し、ホットスポットを分散できます。

戦略6: 店舗間でストレージサイズのバランスをとる必要がある

起動時に、TiKV ストアはstorageのcapacity報告します。これはストアのスペース制限を示します。PD はスケジュール時にこれを考慮します。

戦略7: スケジュール速度を調整してオンラインサービスを安定させる

スケジューリングでは、CPU、メモリ、ネットワーク、および I/O トラフィックが使用されます。リソースの使用率が高すぎると、オンラインサービスに影響します。したがって、PD では同時スケジューリングタスクの数を制限する必要があります。デフォルトではこの戦略は保守的ですが、より迅速なスケジューリングが必要な場合は変更できます。

スケジュールの実装

PD は、ストアハートビートとリージョンハートビートからクラスター情報を収集し、その情報と戦略からスケジュールプランを作成します。スケジュールプランは、一連の基本オペレーターです。PD は、リージョンリーダーからリージョンハートビートを受信するたびに、リージョンに保留中のオペレーターが存在するかどうかを確認します。PD がリージョンに新しいオペレーターをディスパッチする必要がある場合、オペレーターをハートビート応答に置き、後続のリージョンハートビートをチェックしてオペレーターを監視します。

ここでの「演算子」は、リージョンリーダーへの提案にすぎず、リージョンによってスキップされる可能性があることに注意してください。リージョンのLeaderは、現在のステータスに基づいて、スケジューリング演算子をスキップするかどうかを決定できます。