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を設定するには、データの高可用性を参照してください。

実装メカニズム

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

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

強い一貫性のある読み取り

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

Followerレプリカの選択戦略

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

ただし、ポイントクエリなどの非コプロセッサリクエストの場合、Follower Readバランシングポリシーの粒度はトランザクションレベルになります。特定のリージョンの TiDB トランザクションの場合、選択されたフォロワーは固定されており、失敗した場合またはスケジューリングポリシーが調整された場合にのみ切り替えられます。