From 3410cce466f5974769ede7ea022846d6e0ea2c05 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 2d3e76e2a958e..b01f6951b6f24 100644 --- a/follower-read.md +++ b/follower-read.md @@ -66,4 +66,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 ab348d0b60a91b607722182e0f856f77b36e07de 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 b01f6951b6f24..b11719eb73b8f 100644 --- a/follower-read.md +++ b/follower-read.md @@ -66,4 +66,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 85dad69adfd7b74c4a5b75ca2345481dd9553dca 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 b11719eb73b8f..4496ffef27f91 100644 --- a/follower-read.md +++ b/follower-read.md @@ -66,4 +66,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 1823d503d011683b59621d97a5b53dffd839f3d1 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 4496ffef27f91..b0146a8aab98d 100644 --- a/follower-read.md +++ b/follower-read.md @@ -66,4 +66,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.