From fb344d5caed85a0256d5c46e90de03762afa2b30 Mon Sep 17 00:00:00 2001 From: Liu Linkang <1114755877@qq.com> Date: Tue, 9 Jan 2024 22:59:40 +0800 Subject: [PATCH 1/4] translate zh to en --- follower-read.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/follower-read.md b/follower-read.md index 2e58041e4581c..8c3788803cf5c 100644 --- a/follower-read.md +++ b/follower-read.md @@ -65,4 +65,4 @@ When the follower node processes a read request, it first uses `ReadIndex` of th Because the Follower Read feature does not affect TiDB's Snapshot Isolation transaction isolation level, TiDB adopts the round-robin strategy to select the follower replica. Currently, for the coprocessor requests, 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. -However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. +However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both point query and coprocessor requests, the two types of requests will be scheduled for reading separately according to the above scheduling policy. Even if the coprocessor and the point query appear in the same Region, TiDB will processes them as independent events. From 6b107af381c8815b148235e4c1d68b539f12a075 Mon Sep 17 00:00:00 2001 From: Liu Linkang <135819329+llkdd1@users.noreply.github.com> Date: Wed, 10 Jan 2024 13:09:25 +0800 Subject: [PATCH 2/4] Update follower-read.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Daniël van Eeden --- follower-read.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/follower-read.md b/follower-read.md index 8c3788803cf5c..867683dd82630 100644 --- a/follower-read.md +++ b/follower-read.md @@ -65,4 +65,4 @@ When the follower node processes a read request, it first uses `ReadIndex` of th Because the Follower Read feature does not affect TiDB's Snapshot Isolation transaction isolation level, TiDB adopts the round-robin strategy to select the follower replica. Currently, for the coprocessor requests, 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. -However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both point query and coprocessor requests, the two types of requests will be scheduled for reading separately according to the above scheduling policy. Even if the coprocessor and the point query appear in the same Region, TiDB will processes them as independent events. +However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both a point query and coprocessor requests, the two types of requests will be scheduled for reading separately according to the above scheduling policy. Even if the coprocessor and the point query appear in the same Region, TiDB will processes them as independent events. From 9e8a9639589e726ad8d0602ddb147d85429a5718 Mon Sep 17 00:00:00 2001 From: Liu Linkang <135819329+llkdd1@users.noreply.github.com> Date: Thu, 11 Jan 2024 22:30:58 +0800 Subject: [PATCH 3/4] Update follower-read.md Co-authored-by: Grace Cai --- follower-read.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/follower-read.md b/follower-read.md index 867683dd82630..53564e05be142 100644 --- a/follower-read.md +++ b/follower-read.md @@ -65,4 +65,4 @@ When the follower node processes a read request, it first uses `ReadIndex` of th Because the Follower Read feature does not affect TiDB's Snapshot Isolation transaction isolation level, TiDB adopts the round-robin strategy to select the follower replica. Currently, for the coprocessor requests, 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. -However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both a point query and coprocessor requests, the two types of requests will be scheduled for reading separately according to the above scheduling policy. Even if the coprocessor and the point query appear in the same Region, TiDB will processes them as independent events. +However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both point queries and coprocessor requests, the two types of requests are scheduled for reading separately according to the above scheduling policy. In this case, even if a coprocessor request and a point query are for the same Region, TiDB processes them as independent events. From d72b7503a7dcdf2d5feb7bb6729fd3ad9d54cbaf Mon Sep 17 00:00:00 2001 From: Grace Cai Date: Fri, 19 Jan 2024 23:17:32 +0800 Subject: [PATCH 4/4] Update follower-read.md Co-authored-by: xixirangrang --- follower-read.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/follower-read.md b/follower-read.md index 53564e05be142..6a8f413bea93e 100644 --- a/follower-read.md +++ b/follower-read.md @@ -65,4 +65,4 @@ When the follower node processes a read request, it first uses `ReadIndex` of th Because the Follower Read feature does not affect TiDB's Snapshot Isolation transaction isolation level, TiDB adopts the round-robin strategy to select the follower replica. Currently, for the coprocessor requests, 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. -However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both point queries and coprocessor requests, the two types of requests are scheduled for reading separately according to the above scheduling policy. In this case, even if a coprocessor request and a point query are for the same Region, TiDB processes them as independent events. +However, for the non-coprocessor requests, such as a point query, the granularity of the Follower Read load balancing policy is at the transaction level. For a TiDB transaction on a specific Region, the selected follower is fixed, and is switched only when it fails or the scheduling policy is adjusted. If a transaction contains both point queries and coprocessor requests, the two types of requests are scheduled for reading separately according to the preceding scheduling policy. In this case, even if a coprocessor request and a point query are for the same Region, TiDB processes them as independent events.