TiDBスケジューリング

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

スケジューリング状況

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

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

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

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

スケジュール要件

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

1. 分散型で可用性の高いストレージシステムは、次の要件を満たす必要があります。

   • 適切な数のレプリカ。
   • レプリカは、さまざまなトポロジに従ってさまざまなマシンに配布する必要があります。
   • クラスタは、TiKVピアの障害からの自動ディザスタリカバリを実行できます。

2. 優れた分散システムには、次の最適化が必要です。

   • すべてのリージョンリーダーは店舗に均等に配置されます。
   • すべての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で指定された時間を超えると、ステータス「切断」が「ダウン」に変わります。
  • ダウン：PDとTiKVストア間のハートビートメッセージがmax-store-down-time時間以上失われます（デフォルトでは30分）。このステータスでは、TiKVストアは、存続しているストアの各リージョンのレプリカの補充を開始します。
  • オフライン：TiKVストアはPD Controlを介して手動でオフラインになります。これは、ストアがオフラインになるための中間ステータスにすぎません。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の「アップ」ストアに移動します。 leader_countとregion_count （ PD Controlで取得）の両方に0が表示されると、ストアのステータスが「オフライン」から「トゥームストーン」に変わります。 「オフライン」ステータスでは、ストアサービスまたはストアが配置されている物理サーバーを無効にしないでください。ストアがオフラインになるプロセス中に、リージョンを再配置するためのターゲットストアがクラスタにない場合（たとえば、クラスタにレプリカを保持するにはストアが不十分な場合）、ストアは常に「オフライン」ステータスになります。
  • トゥームストーン：TiKVストアは完全にオフラインです。 remove-tombstoneインターフェイスを使用して、このステータスのTiKVを安全にクリーンアップできます。

  

• リージョンのリーダーによって報告された情報：

  各リージョンリーダーは、以下を含むレポートRegionStateに定期的にハートビートをPDに送信します。

  • リーダー自体の位置
  • 他のレプリカの位置
  • オフラインレプリカの数
  • データの読み取り/書き込み速度

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を報告します。これは、ストアのスペース制限を示します。 PDは、スケジューリング時にこれを考慮します。

戦略7：オンラインサービスを安定させるためにスケジューリング速度を調整する

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

スケジューリングの実装

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

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