TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

Follower Read

リージョンに読み取りホットスポットが発生すると、リージョンリーダーがシステム全体の読み取りボトルネックになる可能性があります。このような状況では、Follower Read機能を有効にすると、リーダーの負荷を大幅に軽減し、複数のフォロワー間で負荷を分散することでシステム全体のスループットを向上させることができます。このドキュメントでは、Follower Readの使用と実装のメカニズムを紹介します。

概要

Follower Read機能とは、強力な一貫性のある読み取りを前提として、リージョンの任意のフォロワー レプリカを使用して読み取り要求を処理することです。この機能により、TiDB クラスターのスループットが向上し、リーダーの負荷が軽減されます。これには、TiKV 読み取り負荷をリーダー レプリカからリージョンのフォロワー レプリカにオフロードする一連の負荷分散メカニズムが含まれています。TiKV のFollower Read実装により、ユーザーは強力な一貫性のある読み取りを利用できます。

注記：

強力な一貫性のある読み取りを実現するために、フォロワー ノードは現在、リーダー ノードから現在の実行の進行状況 (つまりReadIndex ) を要求する必要があり、これにより追加のネットワーク要求オーバーヘッドが発生します。したがって、Follower Readの主な利点は、クラスター内の読み取り要求を書き込み要求から分離し、全体的な読み取りスループットを向上させることです。

使用法

TiDB のFollower Read機能を有効にするには、 tidb_replica_read変数の値を次のように変更します。

set [session | global] tidb_replica_read = '<target value>';

範囲: セッション | グローバル

デフォルト: リーダー

この変数は、予想されるデータ読み取りモードを設定するために使用されます。

  • 値tidb_replica_readがleaderまたは空の文字列に設定されている場合、TiDB はデフォルトの動作を維持し、すべての読み取り操作をリーダー レプリカに送信して実行します。

  • 値tidb_replica_readをfollowerに設定すると、TiDB はリージョンのフォロワーレプリカを選択してすべての読み取り操作を実行します。

  • tidb_replica_readの値をleader-and-followerに設定すると、TiDB は任意のレプリカを選択して読み取り操作を実行できます。このモードでは、読み取り要求はリーダーとフォロワーの間で負荷分散されます。

  • tidb_replica_readの値がprefer-leaderに設定されている場合、TiDB は読み取り操作を実行するためにリーダー レプリカを選択することを優先します。リーダー レプリカの読み取り操作の処理が明らかに遅い場合 (ディスクまたはネットワーク パフォーマンスのジッターが原因など)、TiDB は読み取り操作を実行するために他の利用可能なフォロワー レプリカを選択します。

  • 値tidb_replica_readをclosest-replicasに設定すると、TiDB は読み取り操作を実行するために、リーダーまたはフォロワーである同じアベイラビリティ ゾーン内のレプリカを選択することを優先します。同じアベイラビリティ ゾーン内にレプリカがない場合、TiDB はリーダー レプリカから読み取ります。

  • tidb_replica_readの値がclosest-adaptiveに設定されている場合:

    • 読み取り要求の推定結果がtidb_adaptive_closest_read_thresholdの値である場合、TiDB は読み取り操作に同じアベイラビリティ ゾーン内のレプリカを選択することを優先します。アベイラビリティ ゾーン間で読み取りトラフィックの不均衡な分散を回避するために、TiDB はすべてのオンライン TiDB および TiKV ノードのアベイラビリティ ゾーンの分散を動的に検出します。各アベイラビリティ ゾーンでは、 closest-adaptive構成が有効になる TiDB ノードの数が制限されています。これは、TiDB ノードが最も少ないアベイラビリティ ゾーン内の TiDB ノードの数と常に同じであり、他の TiDB ノードは自動的にリーダー レプリカから読み取ります。たとえば、TiDB ノードが 3 つのアベイラビリティ ゾーン (A、B、C) に分散されていて、A と B にそれぞれ 3 つの TiDB ノードが含まれ、C には 2 つの TiDB ノードのみが含まれる場合、各アベイラビリティ ゾーンでclosest-adaptive構成が有効になる TiDB ノードの数は 2 であり、A および B アベイラビリティ ゾーンのそれぞれの他の TiDB ノードは読み取り操作にリーダー レプリカを自動的に選択します。
    • 読み取り要求の推定結果がtidb_adaptive_closest_read_thresholdの値未満の場合、TiDB は読み取り操作に対してリーダー レプリカのみを選択できます。

  • tidb_replica_readの値がlearnerに設定されている場合、TiDB は学習者レプリカからデータを読み取ります。リージョンに学習者レプリカがない場合、TiDB はエラーを返します。

注記：

tidb_replica_readの値がclosest-replicasまたはclosest-adaptiveに設定されている場合、指定された構成に従ってレプリカがアベイラビリティーゾーン全体に分散されるようにクラスターを構成する必要があります。PD にlocation-labels構成し、TiDB と TiKV に正しいlabels設定するには、 トポロジラベルによるレプリカのスケジュールを参照してください。TiDB は、同じアベイラビリティーゾーン内の TiKV ノードと一致するためにzoneラベルに依存するため、PD のlocation-labelsにzoneラベルが含まれ、各 TiDB および TiKV ノードの構成にzone含まれていることを確認する必要があります。クラスターがTiDB Operator を使用してデプロイされている場合は、 データの高可用性を参照してください。

実施メカニズム

Follower Read機能が導入される前、TiDB は強力なリーダー原則を適用し、すべての読み取りおよび書き込み要求をリージョンのリーダー ノードに送信して処理していました。TiKV はリージョンを複数の物理ノードに均等に分散できますが、各リージョンではリーダーのみが外部サービスを提供できます。他のフォロワーは読み取り要求を処理することはできませんが、常にリーダーから複製されたデータを受信し、フェイルオーバーの場合にリーダーを選出するための投票を準備します。

フォロワー ノードで線形化可能性に違反したり、TiDB のスナップショット分離に影響を与えたりすることなくデータの読み取りを可能にするには、フォロワー ノードでRaftプロトコルのReadIndex使用して、読み取り要求がリーダーでコミットされた最新のデータを読み取ることができるようにする必要があります。TiDB レベルでは、Follower Read機能は、負荷分散ポリシーに基づいて、リージョンの読み取り要求をフォロワー レプリカに送信するだけです。

強力な一貫性のある読み取り

フォロワーノードが読み取り要求を処理する場合、最初にRaftプロトコルのReadIndex使用してリージョンのリーダーと対話し、現在のRaftグループの最新のコミットインデックスを取得します。リーダーの最新のコミットインデックスがフォロワーにローカルに適用された後、読み取り要求の処理が開始されます。

Followerレプリカ選択戦略

Follower Read機能は TiDB のスナップショット分離トランザクション分離レベルに影響を与えないため、TiDB はラウンドロビン戦略を採用してフォロワーレプリカを選択します。現在、コプロセッサ要求の場合、Follower Read負荷分散ポリシーの粒度は接続レベルです。特定のリージョンに接続された TiDB クライアントの場合、選択されたフォロワーは固定されており、フォロワーが失敗するか、スケジュール ポリシーが調整された場合にのみ切り替えられます。

ただし、ポイント クエリなどの非コプロセッサ要求の場合、Follower Read負荷分散ポリシーの粒度はトランザクション レベルです。特定のリージョンでの TiDB トランザクションの場合、選択されたフォロワーは固定されており、失敗した場合またはスケジューリング ポリシーが調整された場合にのみ切り替えられます。トランザクションにポイント クエリとコプロセッサ要求の両方が含まれている場合、2 種類の要求は、前のスケジューリング ポリシーに従って個別に読み取り用にスケジュールされます。この場合、コプロセッサ要求とポイント クエリが同じリージョンに対するものであっても、TiDB はそれらを独立したイベントとして処理します。

このページは役に立ちましたか？