【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
这里的文件被误删了，怎么强制下线或者标记忽略呢
这里的文件被误删了，怎么强制下线或者标记忽略呢
sst 文件被删除了吗？是直接在服务器层面删除的吗？
是的，在服务器误删除一个sst
1 个赞
有损恢复
SST 被删了 rocksdb是启动不成功的，你直接把这个节点删掉就行了，tikv是3副本的，再补充一个节点就行了。
curl -X DELETE http: // {pdip}:2379 /pd/api/v1/store/ ${store_id}?force
强删一个store的命令如上。
单个tikv？那岂不是啥都没了。这不是已经tombstone了。你这环境有点不严肃啊。
只删了一个sst，你可以试试这样：
tikv-ctl ldb manifest_dump --path={datadir}/db
这样能列出每个level的sst文件，然后你看看删掉的sst是不是在输出的里面，如果巧了只是compact过程中的一个临时的sst文件，那你这个删除没影响，重启后recover会自动从wal里面读出来。
如果是一个正常的文件，大概率是启动不了了。如果非要忽略试试，那可以找找ldb有没有类似的手段，修改manifest，让manifest认为这个文件本不存在。
鉴于你就1副本，数据也不是多重要吧，丢了就丢了吧，不值当的。
找了找rocksdb还真有：
tikv-ctl ldb --db <dbpath> unsafe_remove_sst_file file_number
同样删除之前注意看下manifest里面，这个sst属于哪个db，哪个cf。如果是真正的数据，tikv或许能启动，如果不是数据，是raft cf中的。那估计启动不了。
如果是raftdb下面的sst，那属于raftlog，如果不包含元数据，说不定有戏。
以上操作执行之前你先复制一份，备份下你的数据。如果不懂，就放弃吧，我也没这么操作过，这只是一个可能能行的方法 
。
6.1.1测试了下按下面方法能把tikv起来
1、复制一个其他sst文件重命名为误删除的文件。选择一个比较小的 文件号靠后的，避免影响系统表。
2、之后就可以执行tikv-ctl ldb unsafe_remove_sst_file 15 --db=/data/v631/tikv/data/db 这里的15就sst文件名的编号。否则这个命令会报错找不到文件。
这种方法会导致 复制的sst文件里也丢失，其他还会丢哪些数据就不知道了