我现在占的磁盘大小是 85%
还有之前 我把FAFT日志 删了 一部分 会有影响吗
还是小了，80%以上的磁盘占用就会告警。不过现在看磁盘还不是根因。这个版本也低了，不行就找一台新机器扩容，缩容一下看看。
其实我还担心你这个集群本来就是最小3tikv部署的，现在挂了一台tikv，极限情况也就挂2个tikv，我担心另外2个tikv的存储也快满了，最好是先扩容一台tikv。再回头来搞这个出问题的tikv。
没啥影响，反正都是起不来，最坏也不过是不好定位原因。
我这边没啥权限 所有我就排查下 先让他起来再说 
扩缩容 增加磁盘 都要上报的 我决定不了
1 个赞
要上报的，再坏一台tikv就集群不可用了。问题不小了。
能不能先把坏的这台下线，把里面 的那些东西删除掉 再重新上扩这台坏的机器
理论上可以，强制缩容这台，再重新布。
不过你一台tikv啥配置，我感觉腾讯云再申请一台在，撑死也就是一个月多几千的成本，至于玩这么极限的操作么。
这几千和数据库的安全比起来，我是老板，我宁可多花点钱。也不要弄得集群整个出问题了。那损失更大。
你还是要确认一下另外两台tikv的存储够用么，我感觉另外2台现在存储也很危险了，不扩容弄个再坏一台tikv，就真的难救了。
[2025/08/05 16:16:55.617 +08:00] [INFO] [node.rs:391] ["start raft store thread"] [store_id=4]
[2025/08/05 16:16:55.617 +08:00] [INFO] [snap.rs:1099] ["Initializing SnapManager, encryption is enabled: false"]
[2025/08/05 16:17:15.509 +08:00] [INFO] [lib.rs:80] ["Welcome to TiKV"]
看起来 TiKV 起来 20s 之后就马上重启了，可以 dmesg 看看有没有 OOM Killer，以及 TiKV 日志文件夹下面有没有 stderr 或者 coredump 文件。另外如果要驱逐这台 TiKV 最好还是先扩后缩。
1 个赞
好的 我现在找找办法 看有机会能起来吗
这里被干掉的看起来也不是 TiKV，tikv 的日志文件夹下面有 stderr 或者 coredump 吗？以及可以看看 data-dir 里面的 rocksdb.info，那是 rocksdb 的日志。
有个stderr 日志文件
tikv_stderr.log (64 KB)
这里面看起来都是很早之前的内容了，似乎也没啥有用的信息……
对啊
rocksdb.info (4.2 MB)
看起来完全就是无疾而终……目前我没啥新发现了。
[2025/08/05 16:16:54.448 +08:00][2][INFO] [db/db_impl/db_impl_open.cc:705] Recovering log #194822905 mode 2
[2025/08/05 16:16:54.457 +08:00][2][INFO] [db/version_set.cc:3751] Creating manifest 194822907
[2025/08/05 16:16:54.631 +08:00][2][WARN] [db/version_set.cc:3248] More existing levels in DB than needed. max_bytes_for_level_multiplier may not be guaranteed.
[2025/08/05 16:16:54.675 +08:00][2][INFO] EVENT_LOG_v1 {"time_micros": 1754381814675353, "job": 1, "event": "recovery_finished"}
...没有任何 ERROR 或者 FATAL
[2025/08/05 16:17:17.276 +08:00][2][INFO] [db/db_impl/db_impl_open.cc:705] Recovering log #194822908 mode 2
[2025/08/05 16:17:17.284 +08:00][2][INFO] [db/version_set.cc:3751] Creating manifest 194822910
[2025/08/05 16:17:17.456 +08:00][2][WARN] [db/version_set.cc:3248] More existing levels in DB than needed. max_bytes_for_level_multiplier may not be guaranteed.
[2025/08/05 16:17:17.501 +08:00][2][INFO] EVENT_LOG_v1 {"time_micros": 1754381837501376, "job": 1, "event": "recovery_finished"}
那是不是就只能扩缩容了
或许可以试着用 tikv-ctl bad-regions 和 tikv-ctl tombstone 移除这些出问题副本。
但是后续日志没有出现这个 FATAL，因此也没法 100% 确定这个是不是问题的根源。我也没有在这种场景恢复的经验，这些也都是比较危险的操作，因此还请谨慎操作，祝你好运。
扩容磁盘，然后再启动下试试吧，别着急扩缩容