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 はエラーを返します。
実施メカニズム
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はそれらを独立したイベントとして処理します。