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 は同じ優先度で読み取り操作の対象としてそれらも考慮します。現在のリージョンに利用可能なフォロワーレプリカまたはラーナーレプリカが存在しない場合、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 は利用可能なリーダーレプリカまたはフォロワーレプリカからデータを読み取ります。
実施メカニズム
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はそれらを独立したイベントとして処理します。