tikv-ctl多副本恢复报错

【版本】v5.2.2
使用tikv-ctl做多副本丢失恢复失报错,测试环境模拟2地3中心中同城双中心失败后的异地恢复
CentOS Linux release 7.7.1908 (Core)

$ /data/tikv-ctl --version
TiKV Control (tikv-ctl)
Release Version: 5.2.2
Edition: Community
Git Commit Hash: 7acaec5d9c809439b9b0017711f114b44ffd9a49
Git Commit Branch: heads/refs/tags/v5.2.2
UTC Build Time: 2021-10-25 12:00:54
Rust Version: rustc 1.56.0-nightly (2faabf579 2021-07-27)
Enable Features: jemalloc mem-profiling portable sse protobuf-codec test-engines-rocksdb cloud-aws cloud-gcp
Profile: dist_release
$ /data/tikv-ctl --data-dir /data/dr_tidb/tidb-data/tikv-20162/db unsafe-recover remove-fail-stores -s 1 --all-regions
[2021/11/20 15:42:04.216 +08:00] [INFO] [mod.rs:118] [“encryption: none of key dictionary and file dictionary are found.”]
[2021/11/20 15:42:04.216 +08:00] [INFO] [mod.rs:479] [“encryption is disabled.”]
[2021/11/20 15:42:04.218 +08:00] [WARN] [config.rs:587] [“compaction guard is disabled due to region info provider not available”]
[2021/11/20 15:42:04.218 +08:00] [WARN] [config.rs:682] [“compaction guard is disabled due to region info provider not available”]thread ’
main’ panicked at ‘called Result::unwrap() on an Err value: Os { code: 2, kind: NotFound, message: “No such file or directory” }’, cmd/tikv-ctl/src/main.rs:121:57
stack backtrace:
0: 0x56263a0b3733 - std::backtrace_rs::backtrace::libunwind::trace::h99dbb39dca18857d
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/…/…/backtrace/src/backtrace/libunwind.rs:90:5
1: 0x56263a0b3733 - std::backtrace_rs::backtrace::trace_unsynchronized::h832861927e9cfedf
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/…/…/backtrace/src/backtrace/mod.rs:66:5
2: 0x56263a0b3733 - std::sys_common::backtrace::_print_fmt::h3d18154c77dcf310
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:67:5
3: 0x56263a0b3733 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::he312f4ad5b9bb346
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:46:22
4: 0x562639ca78dc - core::fmt::write::h9a6d9c74526a6c1b
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/core/src/fmt/mod.rs:1115:17
5: 0x56263a0b1a74 - std::io::Write::write_fmt::h6aced00850e8186f
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/io/mod.rs:1665:15
6: 0x56263a0b27eb - std::sys_common::backtrace::_print::h65d996766de40da4
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:49:5
7: 0x56263a0b27eb - std::sys_common::backtrace::print::h40df9727e635f303
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:36:9
8: 0x56263a0b27eb - std::panicking::default_hook::{{closure}}::hd2da4327dea91a51
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:208:50
9: 0x56263a0b167a - std::panicking::default_hook::h3d55120ad6ada158
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:225:9
10: 0x56263a0b167a - std::panicking::rust_panic_with_hook::hf85dd0bb545e3b55
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:622:17
11: 0x56263a0cb658 - std::panicking::begin_panic_handler::{{closure}}::h736ae969434da9fa
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:519:13
12: 0x56263a0cb5cc - std::sys_common::backtrace::__rust_end_short_backtrace::h6133bb80b1d6c3e0
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:141:18
13: 0x56263a0cb57d - rust_begin_unwind
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:515:5
14: 0x562639931140 - core::panicking::panic_fmt::hcf5f6d96e1dd7099
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/core/src/panicking.rs:92:14
15: 0x562639931472 - core::result::unwrap_failed::he898b02f57993c42
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/core/src/result.rs:1599:5
16: 0x562639b506de - core::result::Result<T,E>::unwrap::h9b15a568fd3d140c
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/core/src/result.rs:1281:23
17: 0x562639b506de - tikv_ctl::new_debug_executor::hf1882f8de30a42ac
at /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/cmd/tikv-ctl/src/main.rs:121:19
18: 0x562639bae8c5 - tikv_ctl::main::h4cba0eebb95eb42a
at /home/jenkins/agent/workspace/optimization-build-tidb-linux-amd/go/src/github.com/pingcap/tikv/cmd/tikv-ctl/src/main.rs:2089:9
19: 0x562639a68213 - core::ops::function::FnOnce::call_once::h9f3fe6e831e531cc
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/core/src/ops/function.rs:227:5
20: 0x562639a68213 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2c86e5c1e2affbe6
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:125:18
21: 0x562639bcc004 - main
22: 0x7fe813111505 - __libc_start_main
23: 0x5626399e7007 -
24: 0x0 -

2 个赞

你这是同时挂了2以上的么?还是只是测试,之前线上发生过这样的问题 按流程操作没问题

1 个赞

https://blog.csdn.net/weixin_36135773/article/details/116274916 来自线上得真实案例

2 个赞

@spc_monkey 大佬有时间帮看下

去掉 /db 的目录试试

大佬就是大佬,官方文档上是不是也更新下

执行成功了吗?

嗯 好使了

OK ,我们更新一下 ~

另外再反馈下这版本上的pd监控 alloc-id这数据源默认不cluster name,集群我重建过几次都是这样
image
image

没懂呀,grafana 里面可以设置一下默认的集群,可以找找看

以pd里的cluster ID这个面板为例,进入编辑状态后数据源内显示是以cluster_name命名的数据源


而alloc-id的数据源是 tidb-cluster-not found。而实际上是该面板也是有以cluster_name命名的数据源,只是默认不是这个,改成这个数据后就有数据了,是不是在做模板时有些变量设置不对,导致自动设置的数据源有问题。

image

你期望的预期是什么样的?


在我这部署的环境中。5.2版本PD-CurrentID allocation面板里的数据源不对,要想看到正确数据需要编辑选择正确数据源。5.0.4中的进去PD页面可直接看到展示的结果
5.0.4
image
5.2.1
image
5.2.2
image

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。