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/4] 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/4] 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 e88f369ef50864c415d4f04ef90785075ac5be57 Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Thu, 19 Dec 2019 14:29:04 +0800 Subject: [PATCH 3/4] reference/performance: refine the Follower Read doc --- dev/reference/performance/follower-read.md | 6 +++--- v3.1/reference/performance/follower-read.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dev/reference/performance/follower-read.md b/dev/reference/performance/follower-read.md index 883dd41b96217..240d77bc56cd1 100644 --- a/dev/reference/performance/follower-read.md +++ b/dev/reference/performance/follower-read.md @@ -10,7 +10,7 @@ When a read hotspot appears in a Region, the Region leader can become a read bot ## 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 reads. 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 linearizability of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent reads. +The Follower Read feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent reads. 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 linearizability of data reading; combined with Snapshot Isolation in TiDB, this implementation provides users with strongly consistent reads. > **Note:** > @@ -37,13 +37,13 @@ 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 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 principle 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 linearizability 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 reads -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. +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 diff --git a/v3.1/reference/performance/follower-read.md b/v3.1/reference/performance/follower-read.md index 883dd41b96217..240d77bc56cd1 100644 --- a/v3.1/reference/performance/follower-read.md +++ b/v3.1/reference/performance/follower-read.md @@ -10,7 +10,7 @@ When a read hotspot appears in a Region, the Region leader can become a read bot ## 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 reads. 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 linearizability of single-row data reading. Combined with Snapshot Isolation in TiDB, this implementation also provides users with strongly consistent reads. +The Follower Read feature refers to using any follower replica of a Region to serve a read request under the premise of strongly consistent reads. 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 linearizability of data reading; combined with Snapshot Isolation in TiDB, this implementation provides users with strongly consistent reads. > **Note:** > @@ -37,13 +37,13 @@ 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 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 principle 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 linearizability 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 reads -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. +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 From 27998d1e5de8a85b22da80a41e9a26f6897aeb9f Mon Sep 17 00:00:00 2001 From: juliezhang1112 <1060074157@qq.com> Date: Fri, 20 Dec 2019 15:30:37 +0800 Subject: [PATCH 4/4] reference/performance: update the format of commit index --- 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 240d77bc56cd1..91a27a3feec73 100644 --- a/dev/reference/performance/follower-read.md +++ b/dev/reference/performance/follower-read.md @@ -43,7 +43,7 @@ To allow data reading in the follower node without violating linearizability or ### Strongly consistent reads -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. +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 diff --git a/v3.1/reference/performance/follower-read.md b/v3.1/reference/performance/follower-read.md index 240d77bc56cd1..91a27a3feec73 100644 --- a/v3.1/reference/performance/follower-read.md +++ b/v3.1/reference/performance/follower-read.md @@ -43,7 +43,7 @@ To allow data reading in the follower node without violating linearizability or ### Strongly consistent reads -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. +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