unsafe remove-failed-stores 后，启动 tidb 节点失败，提示：Data is corrupted, missing data for NOT NULL ...

🪐 TiDB 技术问题
1

【 TiDB 使用环境】测试环境
【 TiDB 版本】v8.1.0

【复现路径】做过哪些操作出现的问题

使用 unsafe remove-failed-stores 强制删除 tikv 节点

【遇到的问题：问题现象及影响】

tidb 节点启动不了，错误日志：
[2024/11/26 14:56:03.738 +08:00] [FATAL] [terror.go:309] [“unexpected error”] [error=“[tikv:10000][components/tidb_query_executors/src/table_scan_executor.rs:425]: Data is corrupted, missing data for NOT NULL column (offset = 5)”] [stack=“github.com/pingcap/tidb/pkg/parser/terror.MustNil\n\t/workspace/source/tidb/pkg/parser/terror/terror.go:309\nmain.createStoreAndDomain\n\t/workspace/source/tidb/cmd/tidb-server/main.go:421\nmain.main\n\t/workspace/source/tidb/cmd/tidb-server/main.go:326\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267”] [stack=“github.com/pingcap/tidb/pkg/parser/terror.MustNil\n\t/workspace/source/tidb/pkg/parser/terror/terror.go:309\nmain.createStoreAndDomain\n\t/workspace/source/tidb/cmd/tidb-server/main.go:421\nmain.main\n\t/workspace/source/tidb/cmd/tidb-server/main.go:326\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267”]

2
  1. 检查 TiKV 节点状态：
  • 确认被删除的 TiKV 节点是否确实存在问题，查看其日志以了解具体原因。
  1. 使用命令移除故障节点：
  • 如果确定节点无法恢复，可以使用以下命令强制移除故障节点：
pd-ctl unsafe remove-failed-stores <store-id>
  • <store-id> 是你要删除的 TiKV 节点的 ID。
  1. 重启 TiDB：
  • 移除故障节点后，尝试重新启动 TiDB 实例，查看是否可以正常启动。
  1. 数据恢复：
  • 如果数据丢失严重，可能需要考虑从备份中恢复数据。

注意事项

  • 使用 unsafe 命令会有数据丢失的风险，务必谨慎操作。
  • 建议在执行此类操作前备份重要数据。
3

表妹，我就是运行

unsafe remove-failed-stores <store-id>

命令后，无法启动 tidb 实例，tikv 节点，pd 节点全部正常，就是 tidb 节点启动不了

4

看起是数据有损坏，unsafe remove-failed-stores 处理了几个 tikv node 了。

5

建议您采取以下步骤：

  • 检查 PD 调度状态：使用 PD Control 工具检查 PD 的调度状态，确认是否有 Region 处于不正常状态，例如 down_peer_region 状态。
  • 修复 SST 文件：如果存在损坏的 SST 文件，使用 tikv-ctl bad-ssts 命令检查并修复这些文件。
  • 手动删除副本：如果某些 Region 的副本状态不正确，可以使用 pd-ctl operator add remove-peer 命令手动删除 TiKV 中的副本。
  • 重启 TiKV 节点：在修复操作完成后，尝试重启 TiKV 节点，以确保所有更改生效。
  • 监控集群状态：在修复过程中，持续监控集群状态，确保所有操作都按预期进行
6

就一个

7

查看了一下，下面是 check 结果

empty-region 24892
oversized-region 1
undersized-region 24730

bad-ssts 命令运行有问题：

tiup ctl:v8.1.0 tikv bad-ssts --pd http://127.0.0.1:2379 --data-dir /home/tidb/tidb-data/tikv-20160

报错：
error: Found argument ‘–data-dir’ which wasn’t expected, or isn’t valid in this context

/home/tidb/tidb-data/tikv-20160 这个目录确实是我的 tikv 数据目录，tikv 节点也是正常运行的

8

三个 tikv 节点都没有 bad-ssts

start to print bad ssts; data_dir:/home/tidb/tidb-data/tikv-20162; db:/home/tidb/tidb-data/tikv-20162/db

corruption analysis has completed

9

这属于表元信息损坏或者行数据损坏了，正常情况下 unsafe recover 不会导致类似的报错，除了unsafe recover 外还有其他操作吗

11

tiup ctl:v8.1.0 tikv bad-ssts --pd=‘http://127.0.0.1:2379’ --data-dir=‘/home/tidb/tidb-data/tikv-20160’

这样试试。报错看上去是–data-dir参数没有被正确识别

12

可能是因为在使用unsafe remove-failed-stores命令强制删除TiKV节点后，导致了数据不一致或损坏。以下是一些可能的解决方案：

  1. 检查并修复数据索引一致性：即使表可以进行正常读写，也不代表数据没有丢失。您可以通过查询受影响的表ID来检查数据索引的一致性。使用以下命令查询受影响的表ID：
SELECT TABLE_SCHEMA, TABLE_NAME, TIDB_TABLE_ID FROM INFORMATION_SCHEMA.TABLES WHERE TIDB_TABLE_ID IN (受影响的表ID列表);

然后，对这些表执行以下命令进行检查：

admin check table 表名;

如果发现不一致的索引，可以通过以下步骤进行修复：

admin repair table 表名;
  1. 多副本失败恢复：如果region的多数副本不可用，但还保留着一份副本（数据没有丢），可以通过以下步骤进行多副本失败恢复：
  • 停止region调度，将limit相关参数调整为0。
  • 停止待下线节点上region涉及的所有的TiKV实例。
  • 在正常的TiKV节点上执行恢复命令：
tikv-ctl --db /data/v5.0.3/tikv/data/db unsafe-recover remove-fail-stores -s 3 -r 1001,1002
  1. 使用pd-ctl工具进行恢复：您可以通过pd-ctl工具来查看恢复进度，并等待恢复成功。使用以下命令查看进度：
./pd-ctl -u{pd_addr} unsafe remove-failed-stores show

等到出现Unsafe recovery finished时，表示移除成功。此时TiKV节点下线，剩余节点能重新调度并提供服务。
4. 重建TiKV节点：如果上述方法都无法解决问题，您可能需要停止失效的TiKV节点，删除TiKV的所有数据，然后重启节点，让新节点从其他正常TiKV上恢复数据。