TiDB スケジューリング

配置Driver( PD ) は、TiDB クラスター内のマネージャーとして機能し、クラスター内のリージョンのスケジュールも設定します。この記事では、PD スケジューリングコンポーネントの設計と中心となる概念を紹介します。

状況のスケジュール設定

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

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

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

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

スケジュール要件

上記の状況は、次の 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で指定した時間を超えると、ステータス「切断」が「ダウン」に変わります。
- Down : PD と TiKV ストア間のハートビートメッセージがmax-store-down-timeを超える時間 (デフォルトでは 30 分) 失われます。このステータスでは、TiKV ストアは、存続しているストア上の各リージョンのレプリカの補充を開始します。
- オフライン: TiKV ストアは、 PD Controlを通じて手動でオフラインになります。これは、ストアがオフラインになるための中間ステータスにすぎません。このステータスのストアは、そのすべてのリージョンを、再配置条件を満たす他の「アップ」ストアに移動します。 leader_countとregion_count ( PD Controlを通じて取得) が両方とも0示す場合、ストアのステータスは「Offline」から「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 はストアハートビートとリージョンハートビートからホットスポットを検出できるため、ホットスポットを分散できます。

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

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

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

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

実装のスケジュール設定

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

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