br: backup may fail for some of tidb-operator deployed clusters #53029
Labels
affects-5.4
This bug affects 5.4.x versions.
affects-6.1
affects-6.5
affects-7.1
affects-7.5
component/br
This issue is related to BR of TiDB.
report/customer
Customers have encountered this bug.
severity/major
type/bug
The issue is confirmed as a bug.
Comments
13 tasks
ti-chi-bot
bot
added
may-affects-5.4
BornChanger
removed
may-affects-5.4
|
/label affects-6.5 |
|
/label affects-7.5 |
|
/label affects-7.1 |
|
Note: this should be fixed in master due to the new
|
YuJuncen
added a commit
to YuJuncen/tidb
that referenced
this issue
May 6, 2024
close pingcap#53029 Signed-off-by: hillium <[email protected]>
13 tasks
mittalrishabh
pushed a commit
to mittalrishabh/tidb
that referenced
this issue
May 30, 2024
) close pingcap#53029 Co-authored-by: 山岚 <[email protected]>
13 tasks
YuJuncen
added a commit
to YuJuncen/tidb
that referenced
this issue
Nov 8, 2024
close pingcap#53029 Signed-off-by: hillium <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Please answer these questions before submitting your issue. Thanks!
1. Minimal reproduce step (Required)
Run a cluster with tidb-operator. And then do some scale-out or something for making CoreDNS responses
no such host.2. What did you expect to see? (Required)
BR should be able to retry this error.
3. What did you see instead (Required)
BR directly fails.
4. What is your TiDB version? (Required)
v6.5.3
Note
Though it seems retrying host name not found errors isn't a good enough idea, in some internal network where DNS name registering is asynchronous and in that case, we may need to wait the service name registration finish. The side-effect is that when we trying to backing up from some host manually and we made a typo, we may need to wait for a long time before BR fails.
The text was updated successfully, but these errors were encountered: