pingcap / pingcap/tidb-operator
PITR stuck when TiKV config is empty
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 1.3k
- Forks
- 540
- Avg merge
- 3d 2h
- Merged PRs (30d)
- 18
Description
Bug Report
What version of Kubernetes are you using?
This bug was introduced in pingcap/tidb-operator#6267.
When running a PITR job, the operator tries to merge the gc-ratio configuration into the existing TiKV configmap. However, this fails if the original TiKV config file is empty.
Workaround: Add any non-empty configuration to the TiKV config file so that the merge can succeed.
config: |
[log]
level = "info"
What version of TiDB Operator are you using?
v1.6.3
What storage classes exist in the Kubernetes cluster and what are used for PD/TiKV pods?
N/A
What's the status of the TiDB cluster pods?
Upgrading
What did you do?
Apply pitr restore job on a empty tikv config cluster.
What did you expect to see?
Restore job performed
What did you see instead?
Restore job stuck. tikv is in upgrade state.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the PITR restore path and the configuration-merge change introduced in pingcap/tidb-operator#6267; reproduce the problem with an empty TiKV config. Done means a PITR restore job completes when the TiKV config is empty while preserving the existing non-empty-config behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- databases, infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100