使用 unsafe-recover remove-fail-stores --all-regions 清理down机store节点后,tikv无法启动

TiDB 版本v4.0.14
问题:使用 unsafe-recover remove-fail-stores -s 219459871,219459872 --all-regions 在tikv节点清空异常down机store后,tikv无法启动,启动报错

[FATAL] [lib.rs:481] [“failed to load_latest_options “Invalid argument: Unable to parse the specified CF option disable_write_stall””] [backtrace=“stack backtrace:\ 0: tikv_util::set_panic_hook::{{closure}}\ at components/tikv_util/src/lib.rs:480\ 1: std::panicking::rust_panic_with_hook\ at src/libstd/panicking.rs:475\ 2: rust_begin_unwind\ at src/libstd/panicking.rs:375\ 3: std::panicking::begin_panic_fmt\ at src/libstd/panicking.rs:326\ 4: engine::rocks::util::new_engine_opt::{{closure}}\ at components/engine/src/rocks/util/mod.rs:158\ core::result::Result<T,E>::unwrap_or_else\ at /rustc/0de96d37fbcc54978458c18f5067cd9817669bc8/src/libcore/result.rs:841\ engine::rocks::util::new_engine_opt\ at components/engine/src/rocks/util/mod.rs:157\ 5: cmd::server::TiKVServer::init_engines\ at cmd/src/server.rs:365\ cmd::server::run_tikv\ at cmd/src/server.rs:100\ 6: tikv_server::main\ at cmd/src/bin/tikv-server.rs:166\ 7: std::rt::lang_start::{{closure}}\ at /rustc/0de96d37fbcc54978458c18f5067cd9817669bc8/src/libstd/rt.rs:67\ 8: main\ 9: __libc_start_main\ 10: \ ”] [location=components/engine/src/rocks/util/mod.rs:158] [thread_name=main]

能说一下,你的操作吗?还有当前集群的情况吗,看你的 tikv 是 panic 了

你说的信息有点少,不知道你的紧急情况,所以我先说一下我这边的想法:
1、你的 tikv 总过多少,现在挂掉了几个?为什么用 这个 unsafe-recover 操作,这个操作会丢失数据

一台物理机单机,单机双tikv节点,导致 store 219459871,219459872 一直处于offline状态。参考tidb文档,在其他正常tikv节点使用unsafe-recover remove-fail-stores -s 219459871,219459872 --all-regions 清理 导致 store 219459871,219459872 后,tikv节点无法启动

单个store, 8w+ region,peer中有故障store副本导致集群报错(Region is missing)。所以才使用 unsafe-recover 清空该store peer

还是有点糊涂
1、你总过 tikv 有多少个?
建议你把你的 拓扑情况发一下(脱敏一下)

tikv : 30个节点 ,宕机:2个

是否是bug ? https://github.com/tikv/tikv/pull/10842 目前版本v 4.0.14

哪这个下线 就好了,然后再扩容进去,是最简单的操作,为啥做这个操作,这个操作是指剩余的副本数量不满足 多数派的时候的 修复动作(极端情况),而且这个操作,会丢失数据的

上面的意思就是说:你进行缩容再扩容操作吧,别执行这个命令了

采用这种方式,就是因为缩容完成不了,物理机直接宕机了。还在请求down机store,导致集群无法访问。

:joy:,好吧,这个不能修复是吧(你这么多 tikv,损失2个节点,就导致业务异常,说明的你 lable 设置 不太合理,这个需要你记一下,后期需要修改调整)
1、具体上面的操作,正规流程建议参考:5.3 多数副本丢失数据恢复指南 · TiDB in Action
2、你上面说的 起不来,是指哪个 tikv 起不来?(上面的操作,正常是在 正常节点上的操作)

我还是确认一下吧,你看看 你这2个 tikv 的lable 是一样的还是不一样的

现在情况如何啊

我也想知道,感觉应该是配置不当导致的问题,楼主没说怎么配置的好借鉴下经验

如果是replica是默认的3,没有设置label,挂了两个tikv,那就可能会丢失部分数据,确实需要unsafe-recover恢复。

看起来像是使用新版的 tikv/rocksdb 打开旧版的 rocksdb db,再次使用旧版的 rocksdb 打开该 db 会出现类似情况 https://github.com/tikv/tikv/issues/11226

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