From 7475d23ce0a887c13a32265d71e09fec3362620f Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Wed, 13 Nov 2019 16:40:58 +0800 Subject: [PATCH 1/8] tools: add sql-mode config for sync-diff-inspector --- dev/reference/tools/sync-diff-inspector/overview.md | 4 ++++ v2.1/reference/tools/sync-diff-inspector/overview.md | 4 ++++ v3.0/reference/tools/sync-diff-inspector/overview.md | 4 ++++ v3.1/reference/tools/sync-diff-inspector/overview.md | 4 ++++ 4 files changed, 16 insertions(+) diff --git a/dev/reference/tools/sync-diff-inspector/overview.md b/dev/reference/tools/sync-diff-inspector/overview.md index f4f10890265c9..35b1d7340fc67 100644 --- a/dev/reference/tools/sync-diff-inspector/overview.md +++ b/dev/reference/tools/sync-diff-inspector/overview.md @@ -185,6 +185,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" # Configuration of the target database instance [target-db] @@ -195,6 +197,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v2.1/reference/tools/sync-diff-inspector/overview.md b/v2.1/reference/tools/sync-diff-inspector/overview.md index 43f564c64c914..74a54a58a8c15 100644 --- a/v2.1/reference/tools/sync-diff-inspector/overview.md +++ b/v2.1/reference/tools/sync-diff-inspector/overview.md @@ -186,6 +186,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" # Configuration of the target database instance [target-db] @@ -196,6 +198,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v3.0/reference/tools/sync-diff-inspector/overview.md b/v3.0/reference/tools/sync-diff-inspector/overview.md index 4803027c2ceba..478b4615c0ef7 100644 --- a/v3.0/reference/tools/sync-diff-inspector/overview.md +++ b/v3.0/reference/tools/sync-diff-inspector/overview.md @@ -186,6 +186,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" # Configuration of the target database instance [target-db] @@ -196,6 +198,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v3.1/reference/tools/sync-diff-inspector/overview.md b/v3.1/reference/tools/sync-diff-inspector/overview.md index 8af47674eb7e6..cb0b76757a45e 100644 --- a/v3.1/reference/tools/sync-diff-inspector/overview.md +++ b/v3.1/reference/tools/sync-diff-inspector/overview.md @@ -185,6 +185,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" # Configuration of the target database instance [target-db] @@ -195,6 +197,8 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" + # Sets the `sql-mode` of the database to parse table structures. + # sql-mode = "" ``` ### Run sync-diff-inspector From 90664bafd2ff5b90d90806d24e6ec28a4a4899ed Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Wed, 13 Nov 2019 16:41:10 +0800 Subject: [PATCH 2/8] Revert "tools: add sql-mode config for sync-diff-inspector" This reverts commit 7475d23ce0a887c13a32265d71e09fec3362620f. --- dev/reference/tools/sync-diff-inspector/overview.md | 4 ---- v2.1/reference/tools/sync-diff-inspector/overview.md | 4 ---- v3.0/reference/tools/sync-diff-inspector/overview.md | 4 ---- v3.1/reference/tools/sync-diff-inspector/overview.md | 4 ---- 4 files changed, 16 deletions(-) diff --git a/dev/reference/tools/sync-diff-inspector/overview.md b/dev/reference/tools/sync-diff-inspector/overview.md index 35b1d7340fc67..f4f10890265c9 100644 --- a/dev/reference/tools/sync-diff-inspector/overview.md +++ b/dev/reference/tools/sync-diff-inspector/overview.md @@ -185,8 +185,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" # Configuration of the target database instance [target-db] @@ -197,8 +195,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v2.1/reference/tools/sync-diff-inspector/overview.md b/v2.1/reference/tools/sync-diff-inspector/overview.md index 74a54a58a8c15..43f564c64c914 100644 --- a/v2.1/reference/tools/sync-diff-inspector/overview.md +++ b/v2.1/reference/tools/sync-diff-inspector/overview.md @@ -186,8 +186,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" # Configuration of the target database instance [target-db] @@ -198,8 +196,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v3.0/reference/tools/sync-diff-inspector/overview.md b/v3.0/reference/tools/sync-diff-inspector/overview.md index 478b4615c0ef7..4803027c2ceba 100644 --- a/v3.0/reference/tools/sync-diff-inspector/overview.md +++ b/v3.0/reference/tools/sync-diff-inspector/overview.md @@ -186,8 +186,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" # Configuration of the target database instance [target-db] @@ -198,8 +196,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" ``` ### Run sync-diff-inspector diff --git a/v3.1/reference/tools/sync-diff-inspector/overview.md b/v3.1/reference/tools/sync-diff-inspector/overview.md index cb0b76757a45e..8af47674eb7e6 100644 --- a/v3.1/reference/tools/sync-diff-inspector/overview.md +++ b/v3.1/reference/tools/sync-diff-inspector/overview.md @@ -185,8 +185,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" # Configuration of the target database instance [target-db] @@ -197,8 +195,6 @@ fix-sql-file = "fix.sql" # Uses the snapshot function of TiDB. # If enabled, the history data is used for comparison. # snapshot = "2016-10-08 16:45:26" - # Sets the `sql-mode` of the database to parse table structures. - # sql-mode = "" ``` ### Run sync-diff-inspector From 7ebc2cdc8b0b6eb8499aca3b221433f183983088 Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Wed, 27 Nov 2019 19:50:31 +0800 Subject: [PATCH 3/8] reference/performance: add follower-reads doc --- dev/TOC.md | 1 + dev/reference/performance/follower-reads.md | 50 ++++++++++++++++++++ v3.1/TOC.md | 1 + v3.1/reference/performance/follower-reads.md | 50 ++++++++++++++++++++ 4 files changed, 102 insertions(+) create mode 100644 dev/reference/performance/follower-reads.md create mode 100644 v3.1/reference/performance/follower-reads.md diff --git a/dev/TOC.md b/dev/TOC.md index d4b9cd8a55140..9228a42fd03ed 100644 --- a/dev/TOC.md +++ b/dev/TOC.md @@ -273,6 +273,7 @@ - [Understanding the Query Execution Plan](/dev/reference/performance/understanding-the-query-execution-plan.md) - [Introduction to Statistics](/dev/reference/performance/statistics.md) - [Optimizer Hints](/dev/reference/performance/optimizer-hints.md) + - [Follower Reads](/dev/reference/performance/follower-reads.md) - [Check the TiDB Cluster Status Using SQL Statements](/dev/reference/performance/check-cluster-status-using-sql-statements.md) - [Execution Plan Binding](/dev/reference/performance/execution-plan-bind.md) - [Statement Summary Table](/dev/reference/performance/statement-summary.md) diff --git a/dev/reference/performance/follower-reads.md b/dev/reference/performance/follower-reads.md new file mode 100644 index 0000000000000..6f132f2b26c1a --- /dev/null +++ b/dev/reference/performance/follower-reads.md @@ -0,0 +1,50 @@ +--- +title: Follower Reads +summary: This document describes the use and implementation of Follower Reads. +category: reference +--- + +# Follower Reads + +When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied,causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. + +## Overview + +Follower reads refers to the use of the follower of a Region to carry out data reading under the premise of strongly consistency read, to improve the throughput of the TiDB cluster and reduce the load of the leader. Follower reads contains a series of load balancing mechanisms that offload TiKV read loads from the leader of a Region to the follower. The implementation of TiKV's follower reads ensures the linearizability of reading a single row of data, and provides strongly consistent read for users combined with the transaction isolation level in TiDB. + +> **Note:** +> +> To achieve strongly consistent read, in the current implementation, the follower incurs additional `ReadIndex` overhead. Therefore, for now, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, the interaction overhead with `ReadIndex` of the Raft protocol is one more time than the traditional leader reads. + +## Usage + +To enable TiDB's follower reads, set the value of the session variable `tidb_replica_read` to `follower`: + +{{}} + +```sql +set @@tidb_replica_read = 'follower'; +``` + +Scope: SESSION + +Default: leader + +This variable is used to set how the current session expects the data to be read： + +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower of the Region to perform all read operations. + +## Implementation mechanism + +Before follower reads was introduced, TiDB applied the strong leader policy and submitted all read and write operations to the leader of a Region to complete. Although TiKV can spread Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services, and the other two followers can do nothing to handle read requests but receive the data replicated from the leader and vote to elect a leader in case of a failover. + +In order to allow data reading in the follower without violating linearizability or affecting the transaction isolation level (Snapshot Isolation), the follower needs to use `ReadIndex` of the Raft protocol, to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, follower reads simply sends read requests to a Region to the follower based on the load balancing policy. + +### Strongly consistent read + +When the follower processes read requests, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of read requests starts. + +### Follower selection strategy + +Because follower reads guarantees linearizability without affecting the transaction isolation level, TiDB can apply Round Robin strategy for selecting the follower. Although TiKV can select any follower to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it may cause significant fluctuation of latency. Currently, the granularity of the load balancing policy of follower reads is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file diff --git a/v3.1/TOC.md b/v3.1/TOC.md index c42b22c4a8734..53769ce193095 100644 --- a/v3.1/TOC.md +++ b/v3.1/TOC.md @@ -272,6 +272,7 @@ - [Understanding the Query Execution Plan](/v3.1/reference/performance/understanding-the-query-execution-plan.md) - [Introduction to Statistics](/v3.1/reference/performance/statistics.md) - [Optimizer Hints](/v3.1/reference/performance/optimizer-hints.md) + - [Follower Reads](/v3.1/reference/performance/follower-reads.md) - [Check the TiDB Cluster Status Using SQL Statements](/v3.1/reference/performance/check-cluster-status-using-sql-statements.md) - [Execution Plan Binding](/v3.1/reference/performance/execution-plan-bind.md) - [Statement Summary Table](/v3.1/reference/performance/statement-summary.md) diff --git a/v3.1/reference/performance/follower-reads.md b/v3.1/reference/performance/follower-reads.md new file mode 100644 index 0000000000000..6f132f2b26c1a --- /dev/null +++ b/v3.1/reference/performance/follower-reads.md @@ -0,0 +1,50 @@ +--- +title: Follower Reads +summary: This document describes the use and implementation of Follower Reads. +category: reference +--- + +# Follower Reads + +When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied,causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. + +## Overview + +Follower reads refers to the use of the follower of a Region to carry out data reading under the premise of strongly consistency read, to improve the throughput of the TiDB cluster and reduce the load of the leader. Follower reads contains a series of load balancing mechanisms that offload TiKV read loads from the leader of a Region to the follower. The implementation of TiKV's follower reads ensures the linearizability of reading a single row of data, and provides strongly consistent read for users combined with the transaction isolation level in TiDB. + +> **Note:** +> +> To achieve strongly consistent read, in the current implementation, the follower incurs additional `ReadIndex` overhead. Therefore, for now, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, the interaction overhead with `ReadIndex` of the Raft protocol is one more time than the traditional leader reads. + +## Usage + +To enable TiDB's follower reads, set the value of the session variable `tidb_replica_read` to `follower`: + +{{}} + +```sql +set @@tidb_replica_read = 'follower'; +``` + +Scope: SESSION + +Default: leader + +This variable is used to set how the current session expects the data to be read： + +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower of the Region to perform all read operations. + +## Implementation mechanism + +Before follower reads was introduced, TiDB applied the strong leader policy and submitted all read and write operations to the leader of a Region to complete. Although TiKV can spread Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services, and the other two followers can do nothing to handle read requests but receive the data replicated from the leader and vote to elect a leader in case of a failover. + +In order to allow data reading in the follower without violating linearizability or affecting the transaction isolation level (Snapshot Isolation), the follower needs to use `ReadIndex` of the Raft protocol, to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, follower reads simply sends read requests to a Region to the follower based on the load balancing policy. + +### Strongly consistent read + +When the follower processes read requests, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of read requests starts. + +### Follower selection strategy + +Because follower reads guarantees linearizability without affecting the transaction isolation level, TiDB can apply Round Robin strategy for selecting the follower. Although TiKV can select any follower to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it may cause significant fluctuation of latency. Currently, the granularity of the load balancing policy of follower reads is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file From 3431c0ef962d08cf767584bb347c228bc5f5ea23 Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Wed, 27 Nov 2019 20:04:27 +0800 Subject: [PATCH 4/8] reference/performance: add a space --- dev/reference/performance/follower-reads.md | 2 +- v3.1/reference/performance/follower-reads.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev/reference/performance/follower-reads.md b/dev/reference/performance/follower-reads.md index 6f132f2b26c1a..49ef75b7f7efb 100644 --- a/dev/reference/performance/follower-reads.md +++ b/dev/reference/performance/follower-reads.md @@ -6,7 +6,7 @@ category: reference # Follower Reads -When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied,causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. +When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied, causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. ## Overview diff --git a/v3.1/reference/performance/follower-reads.md b/v3.1/reference/performance/follower-reads.md index 6f132f2b26c1a..49ef75b7f7efb 100644 --- a/v3.1/reference/performance/follower-reads.md +++ b/v3.1/reference/performance/follower-reads.md @@ -6,7 +6,7 @@ category: reference # Follower Reads -When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied,causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. +When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied, causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. ## Overview From 2c8da55605431b3d6a2fb8a2d66edb6ff20f7890 Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Tue, 3 Dec 2019 20:10:32 +0800 Subject: [PATCH 5/8] reference/performace: improve wording --- dev/reference/performance/follower-reads.md | 24 ++++++++++---------- v3.1/reference/performance/follower-reads.md | 24 ++++++++++---------- 2 files changed, 24 insertions(+), 24 deletions(-) diff --git a/dev/reference/performance/follower-reads.md b/dev/reference/performance/follower-reads.md index 49ef75b7f7efb..266383f810dab 100644 --- a/dev/reference/performance/follower-reads.md +++ b/dev/reference/performance/follower-reads.md @@ -6,19 +6,19 @@ category: reference # Follower Reads -When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied, causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. +When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. ## Overview -Follower reads refers to the use of the follower of a Region to carry out data reading under the premise of strongly consistency read, to improve the throughput of the TiDB cluster and reduce the load of the leader. Follower reads contains a series of load balancing mechanisms that offload TiKV read loads from the leader of a Region to the follower. The implementation of TiKV's follower reads ensures the linearizability of reading a single row of data, and provides strongly consistent read for users combined with the transaction isolation level in TiDB. +The follower reads feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's follower reads implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. > **Note:** > -> To achieve strongly consistent read, in the current implementation, the follower incurs additional `ReadIndex` overhead. Therefore, for now, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, the interaction overhead with `ReadIndex` of the Raft protocol is one more time than the traditional leader reads. +> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. ## Usage -To enable TiDB's follower reads, set the value of the session variable `tidb_replica_read` to `follower`: +To enable TiDB's follower reads, set the value of the `tidb_replica_read` session variable to `follower`: {{}} @@ -30,21 +30,21 @@ Scope: SESSION Default: leader -This variable is used to set how the current session expects the data to be read： +This variable is used to set the data read mode expected by the current session. -- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader to perform. -- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower of the Region to perform all read operations. +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. ## Implementation mechanism -Before follower reads was introduced, TiDB applied the strong leader policy and submitted all read and write operations to the leader of a Region to complete. Although TiKV can spread Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services, and the other two followers can do nothing to handle read requests but receive the data replicated from the leader and vote to elect a leader in case of a failover. +Before the follower reads feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. -In order to allow data reading in the follower without violating linearizability or affecting the transaction isolation level (Snapshot Isolation), the follower needs to use `ReadIndex` of the Raft protocol, to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, follower reads simply sends read requests to a Region to the follower based on the load balancing policy. +To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the follower reads feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. ### Strongly consistent read -When the follower processes read requests, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of read requests starts. +When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. -### Follower selection strategy +### Follower replica selection strategy -Because follower reads guarantees linearizability without affecting the transaction isolation level, TiDB can apply Round Robin strategy for selecting the follower. Although TiKV can select any follower to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it may cause significant fluctuation of latency. Currently, the granularity of the load balancing policy of follower reads is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file +Because the follower reads feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the follower reads load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file diff --git a/v3.1/reference/performance/follower-reads.md b/v3.1/reference/performance/follower-reads.md index 49ef75b7f7efb..266383f810dab 100644 --- a/v3.1/reference/performance/follower-reads.md +++ b/v3.1/reference/performance/follower-reads.md @@ -6,19 +6,19 @@ category: reference # Follower Reads -When you read the Region with hot data in the system, resources of the machine where the Region leader is become fully occupied, causing read bottlenecks. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. +When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. ## Overview -Follower reads refers to the use of the follower of a Region to carry out data reading under the premise of strongly consistency read, to improve the throughput of the TiDB cluster and reduce the load of the leader. Follower reads contains a series of load balancing mechanisms that offload TiKV read loads from the leader of a Region to the follower. The implementation of TiKV's follower reads ensures the linearizability of reading a single row of data, and provides strongly consistent read for users combined with the transaction isolation level in TiDB. +The follower reads feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's follower reads implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. > **Note:** > -> To achieve strongly consistent read, in the current implementation, the follower incurs additional `ReadIndex` overhead. Therefore, for now, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, the interaction overhead with `ReadIndex` of the Raft protocol is one more time than the traditional leader reads. +> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. ## Usage -To enable TiDB's follower reads, set the value of the session variable `tidb_replica_read` to `follower`: +To enable TiDB's follower reads, set the value of the `tidb_replica_read` session variable to `follower`: {{}} @@ -30,21 +30,21 @@ Scope: SESSION Default: leader -This variable is used to set how the current session expects the data to be read： +This variable is used to set the data read mode expected by the current session. -- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader to perform. -- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower of the Region to perform all read operations. +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. ## Implementation mechanism -Before follower reads was introduced, TiDB applied the strong leader policy and submitted all read and write operations to the leader of a Region to complete. Although TiKV can spread Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services, and the other two followers can do nothing to handle read requests but receive the data replicated from the leader and vote to elect a leader in case of a failover. +Before the follower reads feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. -In order to allow data reading in the follower without violating linearizability or affecting the transaction isolation level (Snapshot Isolation), the follower needs to use `ReadIndex` of the Raft protocol, to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, follower reads simply sends read requests to a Region to the follower based on the load balancing policy. +To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the follower reads feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. ### Strongly consistent read -When the follower processes read requests, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of read requests starts. +When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. -### Follower selection strategy +### Follower replica selection strategy -Because follower reads guarantees linearizability without affecting the transaction isolation level, TiDB can apply Round Robin strategy for selecting the follower. Although TiKV can select any follower to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it may cause significant fluctuation of latency. Currently, the granularity of the load balancing policy of follower reads is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file +Because the follower reads feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the follower reads load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file From 253e8ca74ce8e3a9b58465aa031fa1491326ee3a Mon Sep 17 00:00:00 2001 From: lilin90 Date: Wed, 4 Dec 2019 11:20:13 +0800 Subject: [PATCH 6/8] dev, v3.1: update file name and wording --- dev/reference/performance/follower-read.md | 50 ++++++++++++++++++++ dev/reference/performance/follower-reads.md | 50 -------------------- v3.1/reference/performance/follower-read.md | 50 ++++++++++++++++++++ v3.1/reference/performance/follower-reads.md | 50 -------------------- 4 files changed, 100 insertions(+), 100 deletions(-) create mode 100644 dev/reference/performance/follower-read.md delete mode 100644 dev/reference/performance/follower-reads.md create mode 100644 v3.1/reference/performance/follower-read.md delete mode 100644 v3.1/reference/performance/follower-reads.md diff --git a/dev/reference/performance/follower-read.md b/dev/reference/performance/follower-read.md new file mode 100644 index 0000000000000..2fb128900484e --- /dev/null +++ b/dev/reference/performance/follower-read.md @@ -0,0 +1,50 @@ +--- +title: Follower Read +summary: This document describes the use and implementation of Follower Read. +category: reference +--- + +# Follower Read + +When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling the Follower Read feature can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of Follower Read. + +## Overview + +The Follower Read feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's Follower Read implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. + +> **Note:** +> +> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of Follower Read are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. + +## Usage + +To enable TiDB's Follower Read feature, set the value of the `tidb_replica_read` session variable to `follower`: + +{{}} + +```sql +set @@tidb_replica_read = 'follower'; +``` + +Scope: SESSION + +Default: leader + +This variable is used to set the data read mode expected by the current session. + +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. + +## Implementation mechanism + +Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. + +To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the Follower Read feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. + +### Strongly consistent read + +When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. + +### Follower replica selection strategy + +Because the Follower Read feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the Follower Read load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. diff --git a/dev/reference/performance/follower-reads.md b/dev/reference/performance/follower-reads.md deleted file mode 100644 index 266383f810dab..0000000000000 --- a/dev/reference/performance/follower-reads.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Follower Reads -summary: This document describes the use and implementation of Follower Reads. -category: reference ---- - -# Follower Reads - -When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. - -## Overview - -The follower reads feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's follower reads implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. - -> **Note:** -> -> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. - -## Usage - -To enable TiDB's follower reads, set the value of the `tidb_replica_read` session variable to `follower`: - -{{}} - -```sql -set @@tidb_replica_read = 'follower'; -``` - -Scope: SESSION - -Default: leader - -This variable is used to set the data read mode expected by the current session. - -- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. -- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. - -## Implementation mechanism - -Before the follower reads feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. - -To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the follower reads feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. - -### Strongly consistent read - -When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. - -### Follower replica selection strategy - -Because the follower reads feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the follower reads load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file diff --git a/v3.1/reference/performance/follower-read.md b/v3.1/reference/performance/follower-read.md new file mode 100644 index 0000000000000..2fb128900484e --- /dev/null +++ b/v3.1/reference/performance/follower-read.md @@ -0,0 +1,50 @@ +--- +title: Follower Read +summary: This document describes the use and implementation of Follower Read. +category: reference +--- + +# Follower Read + +When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling the Follower Read feature can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of Follower Read. + +## Overview + +The Follower Read feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's Follower Read implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. + +> **Note:** +> +> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of Follower Read are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. + +## Usage + +To enable TiDB's Follower Read feature, set the value of the `tidb_replica_read` session variable to `follower`: + +{{}} + +```sql +set @@tidb_replica_read = 'follower'; +``` + +Scope: SESSION + +Default: leader + +This variable is used to set the data read mode expected by the current session. + +- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. +- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. + +## Implementation mechanism + +Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. + +To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the Follower Read feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. + +### Strongly consistent read + +When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. + +### Follower replica selection strategy + +Because the Follower Read feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the Follower Read load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. diff --git a/v3.1/reference/performance/follower-reads.md b/v3.1/reference/performance/follower-reads.md deleted file mode 100644 index 266383f810dab..0000000000000 --- a/v3.1/reference/performance/follower-reads.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: Follower Reads -summary: This document describes the use and implementation of Follower Reads. -category: reference ---- - -# Follower Reads - -When a read hotspot appears in a Region, the Region leader can become a read bottleneck for the entire system. In this situation, enabling follower reads can significantly reduce the load of the leader, and improve the throughput of the whole system by balancing the load among multiple followers. This document introduces the use and implementation mechanism of follower reads. - -## Overview - -The follower reads feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent read. This feature improves the throughput of the TiDB cluster and reduces the load of the leader. It contains a series of load balancing mechanisms that offload TiKV read loads from the leader replica to the follower replica in a Region. TiKV's follower reads implementation guarantees the linear consistency of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent read. - -> **Note:** -> -> To achieve strongly consistent read, the follower node currently requires additional `ReadIndex` overhead. Therefore, the main benefits of follower reads are to isolate read and write requests of the cluster and to increase overall read throughput. Regarding the latency of a single request, it requires one more interaction overhead with `ReadIndex` of the Raft protocol than the traditional leader reads. - -## Usage - -To enable TiDB's follower reads, set the value of the `tidb_replica_read` session variable to `follower`: - -{{}} - -```sql -set @@tidb_replica_read = 'follower'; -``` - -Scope: SESSION - -Default: leader - -This variable is used to set the data read mode expected by the current session. - -- When the value of `tidb_replica_read` is set to `leader` or an empty string, TiDB maintains its original behavior and sends all read operations to the leader replica to perform. -- When the value of `tidb_replica_read` is set to `follower`, TiDB selects a follower replica of the Region to perform all read operations. - -## Implementation mechanism - -Before the follower reads feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. - -To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the follower reads feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. - -### Strongly consistent read - -When the follower node processes a read request, it first uses `ReadIndex` of the Raft protocol to interact with the leader of the Region, to obtain the latest commit index of the current Raft group. After the latest commit index of the leader is applied locally to the follower, the processing of a read request starts. - -### Follower replica selection strategy - -Because the follower reads feature guarantees linear consistency without affecting Snapshot Isolation, TiDB adopts the round-robin strategy to select the follower replica. Although TiKV can select any follower replica to handle any read request, considering the different replication speed among followers, if the load balancing granularity is too fine, it might cause significant fluctuation of latency. Currently, the granularity of the follower reads load balancing policy is at the connection level. For a TiDB client connected to a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. \ No newline at end of file From e185e9c2ebb7f543abc9ac7c3ea70ed57ca7d356 Mon Sep 17 00:00:00 2001 From: lilin90 Date: Wed, 4 Dec 2019 11:22:14 +0800 Subject: [PATCH 7/8] toc: update file name --- dev/TOC.md | 2 +- v3.1/TOC.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev/TOC.md b/dev/TOC.md index 8c315ff0c6c38..6886d58f71b63 100644 --- a/dev/TOC.md +++ b/dev/TOC.md @@ -274,7 +274,7 @@ - [Understanding the Query Execution Plan](/dev/reference/performance/understanding-the-query-execution-plan.md) - [Introduction to Statistics](/dev/reference/performance/statistics.md) - [Optimizer Hints](/dev/reference/performance/optimizer-hints.md) - - [Follower Reads](/dev/reference/performance/follower-reads.md) + - [Follower Read](/dev/reference/performance/follower-read.md) - [Check the TiDB Cluster Status Using SQL Statements](/dev/reference/performance/check-cluster-status-using-sql-statements.md) - [Execution Plan Binding](/dev/reference/performance/execution-plan-bind.md) - [Statement Summary Table](/dev/reference/performance/statement-summary.md) diff --git a/v3.1/TOC.md b/v3.1/TOC.md index 212349ccb11b2..f4543747fc77d 100644 --- a/v3.1/TOC.md +++ b/v3.1/TOC.md @@ -273,7 +273,7 @@ - [Understanding the Query Execution Plan](/v3.1/reference/performance/understanding-the-query-execution-plan.md) - [Introduction to Statistics](/v3.1/reference/performance/statistics.md) - [Optimizer Hints](/v3.1/reference/performance/optimizer-hints.md) - - [Follower Reads](/v3.1/reference/performance/follower-reads.md) + - [Follower Read](/v3.1/reference/performance/follower-read.md) - [Check the TiDB Cluster Status Using SQL Statements](/v3.1/reference/performance/check-cluster-status-using-sql-statements.md) - [Execution Plan Binding](/v3.1/reference/performance/execution-plan-bind.md) - [Statement Summary Table](/v3.1/reference/performance/statement-summary.md) From 8996df6d360cf455abb6c0511bccba597cf25d7a Mon Sep 17 00:00:00 2001 From: lilin90 Date: Wed, 4 Dec 2019 17:44:13 +0800 Subject: [PATCH 8/8] reference: address the comment --- dev/reference/performance/follower-read.md | 2 +- v3.1/reference/performance/follower-read.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dev/reference/performance/follower-read.md b/dev/reference/performance/follower-read.md index 2fb128900484e..36b4f2f2fde52 100644 --- a/dev/reference/performance/follower-read.md +++ b/dev/reference/performance/follower-read.md @@ -37,7 +37,7 @@ This variable is used to set the data read mode expected by the current session. ## Implementation mechanism -Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. +Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the Follower Read feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy. diff --git a/v3.1/reference/performance/follower-read.md b/v3.1/reference/performance/follower-read.md index 2fb128900484e..36b4f2f2fde52 100644 --- a/v3.1/reference/performance/follower-read.md +++ b/v3.1/reference/performance/follower-read.md @@ -37,7 +37,7 @@ This variable is used to set the data read mode expected by the current session. ## Implementation mechanism -Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other two followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. +Before the Follower Read feature was introduced, TiDB applied the strong leader policy and submitted all read and write requests to the leader node of a Region to handle. Although TiKV can distribute Regions evenly on multiple physical nodes, for each Region, only the leader can provide external services. The other followers can do nothing to handle read requests but receive the data replicated from the leader at all times and prepare for voting to elect a leader in case of a failover. To allow data reading in the follower node without violating linear consistency or affecting Snapshot Isolation in TiDB, the follower node needs to use `ReadIndex` of the Raft protocol to ensure that the read request can read the latest data that has been committed on the leader. At the TiDB level, the Follower Read feature simply needs to send the read request of a Region to a follower replica based on the load balancing policy.