TiDB スケジューリング

Placement 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グループ内のレプリカ間でリージョンリーダーを転送する

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

情報収集

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

各 TiKV ピアによって報告される状態情報:
各 TiKV ピアは定期的にハートビートを PD に送信します。 PD は、ストアが生きているかどうかをチェックするだけでなく、ハートビートメッセージでStoreStateを収集します。 StoreState内容:
- 総ディスク容量
- 利用可能なディスク容量
- リージョン数
- データの読み書き速度
- 送受信されるスナップショットの数 (データはスナップショットを介してレプリカ間で複製される場合があります)
- 店舗が過密かどうか
- ラベル ( トポロジーの認識を参照)
PD コントロールを使用して、TiKV ストアのステータス (アップ、切断、オフライン、ダウン、またはトゥームストーン) を確認できます。以下は、すべてのステータスとその関係の説明です。
- 上: TiKV ストアが営業中です。
- 切断: PD と TiKV ストア間のハートビートメッセージが 20 秒以上失われます。失われた期間がmax-store-down-timeで指定された時間を超えると、ステータス「Disconnect」が「Down」に変わります。
- Down : PD と TiKV ストア間のハートビートメッセージがmax-store-down-time時間以上失われます (デフォルトでは 30 分)。この状態で、TiKV ストアは存続しているストアで各リージョンのレプリカの補充を開始します。
- オフライン: TiKV ストアは、 PD Controlを介して手動でオフラインにされます。これは、ストアがオフラインになるための中間ステータスにすぎません。この状態のストアは、すべてのリージョンを、移転条件を満たす他の "Up" ストアに移動します。 leader_countとregion_count ( PD Controlで取得) が両方とも0の場合、ストアのステータスは「オフライン」から「トゥームストーン」に変わります。「オフライン」状態では、ストアサービスやストアが配置されている物理サーバーを無効にしないでください。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲットストアがない場合 (たとえば、クラスター内にレプリカを保持するためのストアが不十分な場合)、ストアは常に "オフライン" ステータスになります。
- Tombstone : 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 は店舗のハートビートとリージョンのハートビートからホットスポットを検出できるため、PD はホットスポットを分散できます。

戦略 6: 保管サイズは店舗間でバランスを取る必要がある

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

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

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

実装のスケジューリング

PD は、ストアハートビートとリージョンハートビートからクラスター情報を収集し、情報と戦略からスケジューリング計画を立てます。スケジューリング計画は、一連の基本的な演算子です。 PD は、リージョンリーダーからリージョンハートビートを受信するたびに、リージョンに保留中のオペレーターがあるかどうかを確認します。 PD がリージョンに新しいオペレーターを派遣する必要がある場合、オペレーターをハートビート応答に入れ、フォローアップリージョンハートビートをチェックしてオペレーターを監視します。

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