Update description of tidb_replica_read variable values for follower read

[tommygood]

First-time contributors' checklist

• I've signed Contributor License Agreement that's required for repo owners to accept my contribution.

What is changed, added or deleted? (Required)

• After reviewing the source code for client-go and TiDB, I noticed that some descriptions in the follower read doc do not fully align with the source code behavior and my test results.

1. Behavior of tidb_replica_read set to leader
   • According to client-go, when tidb_replica_read is set to leader, if the leader replica's kv store is busy, which is partially determined by the tidb_load_based_replica_read_threshold, then the client-go will select the others replica to read, which can be follower or learner replicas.
   • I have updated the doc to reflect this behavior and clarify the relationship between tidb_load_based_replica_read_threshold and tidb_replica_read when set to leader.
2. Reading from Learner Replicas
   • Since reading from learner replicas is supported in the current version, I found it necessary to distinguish between reading from follower and learner replicas.
   • There are generally no restrictions on reading from learner replicas when tidb_replica_read is set to follower, leader-and-follower, prefer-leader, or closest-replicas. However, the current documentation only mentions follower reads in these contexts.
   • More details on how replicas are chosen based on scores can be found in the client-go calculateScore.
3. Behavior when tidb_replica_read is set to learner

   • The doc currently states that :

     When the value of tidb_replica_read is set to learner, TiDB reads data from the learner replica. If there is no learner replica in the Region, TiDB returns an error.

   • However, in my test results (under v8.1.0), when there are no learner replica and tidb_replica_read is set to learner, mysql client still can read data from tidb.This occurs because client-go will randomly choose the leader or follower replica to read.

• Please let me know If I have misunderstood any concepts, Thanks !

Which TiDB version(s) do your changes apply to? (Required)

Tips for choosing the affected version(s):

By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.

For details, see tips for choosing the affected versions.

• master (the latest development version)
• v8.4 (TiDB 8.4 versions)
• v8.3 (TiDB 8.3 versions)
• v8.2 (TiDB 8.2 versions)
• v8.1 (TiDB 8.1 versions)
• v8.0 (TiDB 8.0 versions)
• v7.5 (TiDB 7.5 versions)
• v7.1 (TiDB 7.1 versions)
• v6.5 (TiDB 6.5 versions)
• v6.1 (TiDB 6.1 versions)
• v5.4 (TiDB 5.4 versions)
• v5.3 (TiDB 5.3 versions)
• v5.2 (TiDB 5.2 versions)

What is the related PR or file link(s)?

• This PR is translated from:
• Other reference link(s):

Do your changes match any of the following descriptions?

• Delete files
• Change aliases
• Need modification after applied to another branch
• Might cause conflicts after applied to another branch

[CLAassistant]

All committers have signed the CLA.

[ti-chi-bot]

Welcome @tommygood!

It looks like this is your first PR to pingcap/docs 🎉.

I'm the bot to help you request reviewers, add labels and more, See available commands.

We want to make sure your contribution gets all the attention it needs!



Thank you, and welcome to pingcap/docs. 😃

[ti-chi-bot]

Hi @tommygood. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign qiancai for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cfzjywxk]

@tommygood

Sorry for the late response, thanks for your feedback.

Some of the functional behavior descriptions mentioned above do indeed differ from the actual code implementation as you have mentioned in this PR. My thought is to separate the description of the functionality design from the error handling logic, as users are primarily concerned with the behavior of the functionality itself.

Error handling and retries are part of a more complex internal process (Ref: tikv/client-go#1167) and may require a separate document for detailed explanation.

[tommygood]

Got it, thanks for your response.