TiDB Region失效，查不到数据

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】
生产环境 v4.0.12

【概述】：场景 + 问题概述
现网发现有个表查不到数据了，count数为0；
但是该表并未执行过删除等操作。
在 INFORMATION_SCHEMA.TABLES 里看该表也是有数据的。
该表有一个region，三个副本正常。

【背景】：做过哪些操作
TiKV 节点磁盘故障，缩容，修复，再重新扩容回来。

【现象】：业务和数据库现象

【问题】：当前遇到的问题

【业务影响】：

【TiDB 版本】：
v4.0.12

【附件】：

2

select * limit … 可以查到么，扩容前 count 有多少

1 个赞
3

查不到，二十几万吧

1 个赞
4

INFORMATION_SCHEMA.TABLES 是之前统计信息里面记录的，并不代表实时的信息

1 个赞
5

那先把 gc life time 调大一些，然后设置 tidb snapshot 时间为扩容前看能不能查到

1 个赞
6

扩容已经几天了，gc left time 支持调整那么长吗；
这个会对现网其他查询造成影响吗？

1 个赞
7

几天前的数据应该没有了，默认 gc life time 10分钟

1 个赞
8

那难道数据是丢了吗？三副本，8个kv节点。

1 个赞
9

需要排查下是否执行过 delete 或 truncate 这类操作

1 个赞
10

没有执行过
有几个问题哈
1，背景是 总共有8个tikv节点，tikv节点A磁盘坏了（一周前），缩容掉A，还没扩上去的时候，tikv节点B又坏了（三天前），缩容掉B。。然后A修复了，再把A扩上去。
2，都已经好几天了，为什么 INFORMATION_SCHEMA.TABLES 查看该表还是有数据的。
3，怎么查看region 的大小？我参考https://docs.pingcap.com/zh/tidb/stable/tikv-control 中 tikv-ctl --db /path/to/tikv/db size -r 2 ，/path/to/tikv/db 是指的什么？
4，想问下怎么查看 region 对应的文件在哪里，想去看下三个副本的文件，到底有没有数据。

1 个赞
11

看了下有其他表 P表 也只有这一个region，跟损坏表是相同的region，但是 P表的数据就没问题。

1 个赞
12
  1. 需要确认磁盘故障上面的文件是不是丢失了，B 节点坏掉时，A 节点缩容的最终状态是什么，A 修复后是不是数据目录的文件丢失了
  2. 这个表里记录的是上次收集统计信息时的数据，并不是实时的，如果重新 analyze 下应该就看不到了
  3. 可以用 tikv-ctl 查看 region 大小或者 pd-ctl 查看最近一次上报的 region 信息，/path/to/tikv/db 是指 tikv 数据目录下的 rocksdb 目录，tiup display 可以看到数据目录 data dir
  4. region 对应的 sst 文件可以用 tikv-ctl 查看 region-properties 属性
1 个赞
13

1，A节点tikv服务直接down了，然后就执行了缩容A节点操作，但过了几个小时都没变成Tombstone状态，我认为程序挂了，应该就没法进行同步操作了，就手动将A节点置为了Tombstone状态。A修复后数据文件都丢了。
2，我删了下其他表的数据，发现 INFORMATION_SCHEMA.TABLES 的信息会变的；而且好像没权限 analyze 这个表。
3，新扩入的节点deploy目录和data目录都和其他tikv节点不一致，是按新规范来的，这个应该没影响吧。
4，查询该表，并没有报 Region is unavailable 的错，是不是说明，并不是三副本中两个副本损坏，导致的region不可用。

14
  1. 不建议手动设置 tombstone（无法回退），单个节点挂掉会自动选举新 leader，并在其他可用节点上新增副本，不会导致程序挂或同步问题
  2. 可以 show stats_meta 这个表的统计信息什么时候更新的
  3. 没影响
  4. 没有 unavailable 报错，说明 region group 状态正常。
    可以查一下数据库还有哪些有权限的用户，其他用户有没有可能执行了 delete 或者 admin show ddl jobs 查看历史 DDL
15

show ddl 看了下没有这个表的信息。

show stats_meta where db_name=‘INFORMATION_SCHEMA’ and table_name = ‘TABLES’; 啥也没有。

INFORMATION_SCHEMA.TABLES 这个表是按行刷新的吗

16

这里的 db_name 和 table_name 应该是要查的那个表，而不是系统表

17

嗯，损坏表的话，显示的时间是30号下午16点，但是ddl 里面却没有。

18

这个集群还有其他用户使用么，默认如果用 root 用户登录应该有 analyze table 相关权限

19

前面说是三天前 B 节点故障，故障后业务有没有什么报错，有没有用 tikv-ctl 做过不完全恢复

20

有其他用户使用，但是我是用的 root 用户 analyze table INFORMATION_SCHEMA.TABLES，发现没权限。
没有做过不完全恢复。就和A操作一样。