Update garbage collection docs (#4552)

[ti-srebot]

cherry-pick #4552 to release-5.0
You can switch your code base to this Pull Request by using git-extras:

# In docs repo:
git pr https://github.com/pingcap/docs/pull/5055

After apply modifications, you can push your change to this PR via:

git push [email protected]:ti-srebot/docs.git pr/5055:release-5.0-ca331fb386d4

---

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)

This updates the docs for pingcap/tidb#21988 (now merged).

21988 still allows the previous methods for updating, but because these changes are not validated, they should not be recommended. Incorrect configuration can lead to strange behaviors.

Partially address #4549 (for backup page mentioned, there are still other pages that need readability improvements)

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

• master (the latest development version)
• v5.0 (TiDB 5.0 versions)
• v4.0 (TiDB 4.0 versions)
• v3.1 (TiDB 3.1 versions)
• v3.0 (TiDB 3.0 versions)
• v2.1 (TiDB 2.1 versions)

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

• *: Move tikv gc configuration to sysvars tidb#21988

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

[ti-srebot]

@morgo you're already a collaborator in bot's repo.

[yikeke]

Do we need to merge this PR after 5.0 GA is released? @morgo

[morgo]

I don't quite understand how the docs branching is being done for 5.0. I thought since tidb created release-5.0 from master last week (abandoning release-5.0-rc) that docs would need to do similar, and recreate the release-5.0 branch.

It looks like PRs are being held (for example: #5007 ), but I think it's fine to merge and say a change is effective since 5.0 even when 5.0 is not yet released? I have noticed we do this with point releases too (not merge docs related to a 4.0.11 feature until 4.0.11 is released). It increases merge conflicts/management pains to keep the PRs open.

[yikeke]

I don't quite understand how the docs branching is being done for 5.0. I thought since tidb created release-5.0 from master last week (abandoning release-5.0-rc) that docs would need to do similar, and recreate the release-5.0 branch.

I'd like to transfer this conversation to Slack if you don't mind. I've shared the docs branching plan with you there. We can continue our discussion there.

It looks like PRs are being held (for example: #5007 ), but I think it's fine to merge and say a change is effective since 5.0 even when 5.0 is not yet released? I have noticed we do this with point releases too (not merge docs related to a 4.0.11 feature until 4.0.11 is released). It increases merge conflicts/management pains to keep the PRs open.

merge and say a change is effective since 5.0 even when 5.0 is not yet released this one is hard to do. Two reasons: 1. for example #5007, there are small changes in several documents. We can't write a notice for every small change. 2. We want to reduce as many version-specific descriptions as possible on master, so we try to avoid a statement like "a change is effective since 5.0". Again, this problem is related to the docs release strategy, we can discuss it in detail on Slack.

[bb7133]

Please get me involved, what is the proper time to merge it?

[yikeke]

Now is the time to merge. We have aborted the auto-deployment for the release-5.0 branch.

[ti-chi-bot]

[REVIEW NOTIFICATION]

This pull request has been approved by:

• yikeke

To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.

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

Reviewer can indicate their review by writing /lgtm in a comment.
Reviewer can cancel approval by writing /lgtm cancel in a comment.

[yikeke]

/merge

[ti-chi-bot]

This pull request has been accepted and is ready to merge.

Commit hash: 1837c72