【TiDB 使用环境】生产环境
【TiDB 版本】v4.0.8
【操作系统】centos 7
【部署方式】机器部署nvme盘
报错信息如下：
[2025/05/07 18:01:46.230 +08:00] [FATAL] [lib.rs:483] [“rocksdb background error. db: kv, reason: compaction, error: Corruption: block checksum mismatch: expected 3877266098, got 393113608 in /tidb1/tikv-20171/data/db/24011866.sst offset 3600964 size 10457”] [backtrace=“stack backtrace:\n 0: tikv_util::set_panic_hook::{{closure}}\n at components/tikv_util/src/lib.rs:482\n 1: std::panicking::rust_panic_with_hook\n at src/libstd/panicking.rs:475\n 2: rust_begin_unwind\n at src/libstd/panicking.rs:375\n 3: std::panicking::begin_panic_fmt\n at src/libstd/panicking.rs:326\n 4: <engine_rocks::event_listener::RocksEventListener as rocksdb::event_listener::EventListener>::on_background_error\n at components/engine_rocks/src/event_listener.rs:66\n 5: rocksdb::event_listener::on_background_error\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/src/event_listener.rs:254\n 6: _ZN24crocksdb_eventlistener_t17OnBackgroundErrorEN7rocksdb21BackgroundErrorReasonEPNS0_6StatusE\n at crocksdb/c.cc:2140\n 7: _ZN7rocksdb12EventHelpers23NotifyOnBackgroundErrorERKSt6vectorISt10shared_ptrINS_13EventListenerEESaIS4_EENS_21BackgroundErrorReasonEPNS_6StatusEPNS_17InstrumentedMutexEPb\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/db/event_helpers.cc:53\n 8: _ZN7rocksdb12ErrorHandler10SetBGErrorERKNS_6StatusENS_21BackgroundErrorReasonE\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/db/error_handler.cc:220\n 9: _ZN7rocksdb6DBImpl20BackgroundCompactionEPbPNS_10JobContextEPNS_9LogBufferEPNS0_19PrepickedCompactionENS_3Env8PriorityE\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/db/db_impl/db_impl_compaction_flush.cc:2797\n 10: _ZN7rocksdb6DBImpl24BackgroundCallCompactionEPNS0_19PrepickedCompactionENS_3Env8PriorityE\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/db/db_impl/db_impl_compaction_flush.cc:2317\n 11: _ZN7rocksdb6DBImpl16BGWorkCompactionEPv\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/db/db_impl/db_impl_compaction_flush.cc:2092\n 12: _ZN7rocksdb14ThreadPoolImpl4Impl8BGThreadEm\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/util/threadpool_imp.cc:266\n 13: _ZN7rocksdb14ThreadPoolImpl4Impl15BGThreadWrapperEPv\n at /rust/git/checkouts/rust-rocksdb-a9a28e74c6ead8ef/cf9871d/librocksdb_sys/rocksdb/util/threadpool_imp.cc:307\n 14: execute_native_thread_routine\n 15: start_thread\n 16: __clone\n”] [location=components/engine_rocks/src/event_listener.rs:66] [thread_name=]
查看磁盘和系统无报错， 是触发了什么bug吗
block checksum mismatch: expected 3877266098, got 393113608 in /tidb1/tikv-20171/data/db/24011866.sst offset 3600964 size 10457
这个意思是指 rocksdb 检测内存中的 checksum 和本地文件 sst checksum 对不上。认为文件损坏了(或者说数据异常)。
修复方法你试试缩容这个节点然后扩容 tikv 节点来解决。
我遇到过一次类似情况是系统内存刷盘 内核 bug。。。。
sst 文件损坏了，这个tikv起不来了。幸好有3副本，缩掉重建就可以。
不过，如果你头铁，就非得要修好，也有办法:
- 用ldb工具，查这个sst对应的 cf、属于哪一层，对应的key的范围。
- 查这个范围对应的region，其中 不同的 cf 的 key 又有不同的前缀，
- 用 ldb 工具，unsafe 移除这个sst
- 用 tikv-ctl 工具，unsafe 移除对应的region的peer。
再启动就行了。这一片损失的数据就相当于删掉了。
以上是理论，我没这么修过。
1 个赞
是版本问题吗
数据量不大的话，扩容缩容最快
我是扩缩容解决的， 但是最近这个有点频繁， 一周两次了 
服务器该换了。tidb 版本也升级下，新版本有 sst 文件损坏自我修复。