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 ノードのアベイラビリティ ゾーンの分散を動的に検出します。各アベイラビリティーゾーンでは、構成が有効になる TiDB ノードの数は制限されており、これは常に TiDB ノードが最も少ないアベイラビリティーゾーン内の TiDB ノードの数と同じであり、他の TiDB ノードはリーダーレプリカからclosest-adaptiveに読み取られます。 。たとえば、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ラベルに依存するため、 zoneラベルが PD のlocation-labelsに含まれ、 zoneが各 TiDB および TiKV ノードの構成に含まれていることを確認する必要があります。クラスターが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 トランザクションの場合、選択されたフォロワーは固定されており、失敗した場合またはスケジューリング ポリシーが調整された場合にのみ切り替えられます。

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