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

フォロワー読み取り

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

概要

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

ノート：

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

使用法

TiDB の Follower Read 機能を有効にするには、変数tidb_replica_readの値をfollowerまたはleader-and-followerに変更します。

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の値がclosest-replicasに設定されている場合、TiDB は同じリージョン内のレプリカを選択して読み取り操作を実行することを優先します。これは、リーダーまたはフォロワーである可能性があります。同じリージョンにレプリカがない場合、TiDB はリーダー レプリカから読み取ります。
  • tidb_replica_readの値がclosest-adaptiveに設定されている場合、読み取り要求の推定結果がtidb_adaptive_closest_read_thresholdの値以上である場合、TiDB は同じリージョン内のレプリカからの読み取りを優先します。それ以外の場合、TiDB はリーダー レプリカから読み取ります。さまざまなリージョンで読み取りトラフィックの分散が不均衡になるのを防ぐために、TiDB はすべてのオンライン TiDB および TiKV ノードのリージョン分散がバランスが取れているかどうかを動的に検出します。リージョンに TiDB または TiKV ノードのみが含まれている場合、TiDB は強制的にリーダー レプリカを選択して読み取り操作を実行します。たとえば、リージョン内のすべての TiDB ノードがダウンしている場合、他のオンライン TiDB ノードはリーダー レプリカを使用して読み取るようにダウングレードされます。このリージョンの少なくとも 1 つの 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を使用してデプロイされている場合は、 データの高可用性を参照してください。

実施メカニズム

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

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

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

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

フォロワーレプリカ選択戦略

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

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