TiDB 8.5 TiKV 容量、Store 与 Region 日常检查记录

这篇内容主要是把 Store 容量、Region 分布和副本状态的巡检补上，再关联到 HIS、EMR、LIS 和集成平台的业务表。

Oracle 的容量检查通常围绕表空间、数据文件和 ASM Diskgroup 展开。TiKV 按 Key Range 划分 Region，副本分布在不同 Store 上。 TiKV 磁盘占用偏高，需要结合 Region 分布和文件系统占用检查。

一、环境与副本关系

沿用前文的环境配置，每台 TiKV 主机部署一个实例，对应一个 Store。

业务库为 his_lab、emr_lab、lis_lab、hip_lab。本文采用默认三投票副本，不配置 TiFlash 或额外的副本放置规则。

TiKV 是 TiDB 的行存储层。Region 对应一段连续的 Key Range，是数据复制和调度的基本单位；Peer 是 Region 的一个副本，保存在某个 Store 上。正常情况下，一个 Region 有一个 Leader，其余投票副本为 Follower，默认由 Leader 处理读写请求。三投票副本下，Raft 日志提交需要至少两个副本确认。副本之间通过 Raft 保持一致，PD 负责副本放置和调度。

二、查看 Store 容量和状态

先从 TIKV_STORE_STATUS 查各 Store 的状态、容量和心跳时间：

SELECT
    STORE_ID,
    ADDRESS,
    STORE_STATE_NAME,
    VERSION,
    CAPACITY,
    AVAILABLE,
    LEADER_COUNT,
    REGION_COUNT,
    START_TS,
    LAST_HEARTBEAT_TS,
    UPTIME
FROM information_schema.TIKV_STORE_STATUS
ORDER BY STORE_ID;

这个系统表通过 PD API 获取 Store 信息。STORE_STATE_NAME 的取值为 Up、Offline、Tombstone。Up 是 Store 的状态标记，仍需结合 LAST_HEARTBEAT_TS 判断心跳是否及时。

结果只展示主要字段：

三台 Store 容量相同，剩余空间接近，Leader 没有明显集中。这里共有 3762 个 Region，三台 Store 各保存一份副本，Leader 数合计也是 3762。

在本文这种三 Store、每个 Region 三副本、没有缺副本的稳定状态下，各 Store 持有的 Region 集合应相同。心跳更新、Region 分裂或合并期间，查询可能出现短暂差异，持续不一致需要继续检查。Leader 数不要求完全相等。

如果某台 Store 的剩余空间从平时的 1 TiB 左右降到两三百 GiB，而其他两台变化不大，需要继续核对数据增长和文件占用。

三、容量字段的单位

CAPACITY 和 AVAILABLE 是带单位的字符串，例如 1.80 TiB、620 GiB，不能直接按数值字段相除。巡检时可以直接查看；需要计算使用率或看趋势时，用 Grafana 的原始字节指标，避免在 SQL 中拆分不同单位的字符串。

LEADER_SIZE、REGION_SIZE 和 APPROXIMATE_SIZE 是数值字段，官方系统表文档将单位写为 MB。PD v8.5.0 实际按 1024 × 1024 字节换算 Region 大小，即 MiB；下文除以 1024 后用 GiB 标注。

四、低空间告警与 PD 阈值

官方默认告警 TiKV_low_space 按单个 TiKV 的可用空间与容量之比判断，条件为：

available / capacity < 0.2

TiKV_space_used_more_than_80% 则检查集群汇总的空间使用率。两者的统计范围不同，单节点空间不足可能先于集群整体告警出现。

PD 的 low-space-ratio 默认是 0.8，表示 Store 空间占用比例的阈值。超过后，PD 会尽量避免向该 Store 迁入数据，并在调度时考虑剩余空间。

80% 可以作为检查起点。扩容时间还要结合增长速度、准备周期和临时空间开销来定。每天增长几 GiB 和每天增长几百 GiB，即使都剩 20%，处理时间也不同。

五、单个 Store 空间下降

假设剩余空间变成下面这样：

把 REGION_SIZE 和操作系统 df 的结果对照。如果 Region 数据量接近，但某台主机磁盘占用明显偏高，就继续检查日志、Snapshot、core dump 和其他文件。PD_cluster_low_space 的官方处理建议也包括这些检查项。

Snapshot 本身也是 TiKV 运行过程中产生的文件，占用空间不等于当前 Region 数据量。没有查清占用来源前，不能仅凭 AVAILABLE 的差异调整 PD 调度参数。

六、查看 Region 和 Leader 分布

容量之外，再查各 Store 的 Region 和 Leader：

SELECT
    STORE_ID,
    ADDRESS,
    LEADER_COUNT,
    LEADER_SIZE,
    REGION_COUNT,
    REGION_SIZE
FROM information_schema.TIKV_STORE_STATUS
ORDER BY STORE_ID;

这些字段描述的是 Store 上的 Region 分布。REGION_SIZE 不能直接当成文件系统已用空间，LEADER_SIZE 也不能单独反映读写负载。

在 Store 多于副本数的集群里，两个 Store 即使 Region 数相同，也可能保存不同的 Region，数据量仍会有差异。本文三 Store、三副本的前提下，各 Store 的 Region 集合相同，磁盘占用差异则还要看压缩、存储引擎文件和日志等因素。

七、统计 Region 数量

下面这条 SQL 统计的是系统表行数：

SELECT COUNT(*)
FROM information_schema.TIKV_REGION_STATUS;

同一个 Region 可能同时覆盖表数据和索引数据，在 TIKV_REGION_STATUS 中对应多行记录。统计 Region 数量需要按 REGION_ID 去重。

SELECT
    COUNT(DISTINCT REGION_ID) AS region_count
FROM information_schema.TIKV_REGION_STATUS;

按业务库查看：

SELECT
    DB_NAME,
    COUNT(DISTINCT REGION_ID) AS region_count
FROM information_schema.TIKV_REGION_STATUS
WHERE DB_NAME IN (
    'his_lab',
    'emr_lab',
    'lis_lab',
    'hip_lab'
)
GROUP BY DB_NAME
ORDER BY DB_NAME;

这张表用于定位涉及 Region 较多的业务库。它不统计副本数，也不能据此给数据库磁盘占用排序。如果 Region 跨越多个业务对象的键范围，分组结果还可能重复计入同一个 Region，各库数量不宜直接相加作为集群总数。

八、查看具体业务表的 Region

以 HIS 门诊记录表 outpatient_visit 为例。先按 Region 去重，再汇总数量和大小：

SELECT
    DB_NAME,
    TABLE_NAME,
    COUNT(*) AS region_count,
    ROUND(
        SUM(APPROXIMATE_SIZE) / 1024,
        2
    ) AS related_regions_gib
FROM
(
    SELECT
        DB_NAME,
        TABLE_NAME,
        REGION_ID,
        MAX(APPROXIMATE_SIZE) AS APPROXIMATE_SIZE
    FROM information_schema.TIKV_REGION_STATUS
    WHERE DB_NAME = 'his_lab'
      AND TABLE_NAME = 'outpatient_visit'
      AND IS_INDEX = 0
    GROUP BY
        DB_NAME,
        TABLE_NAME,
        REGION_ID
) r
GROUP BY
    DB_NAME,
    TABLE_NAME;

IS_INDEX = 0 选取与表记录键范围相关的 Region，不包含仅覆盖索引键范围的 Region。APPROXIMATE_SIZE 仍是整个 Region 的大小。如果一个 Region 同时包含索引或其他表的数据，这部分大小也会计入，不能把汇总值当成 outpatient_visit 独占的空间。

related_regions_gib 按单份 Region 数据统计，没有乘副本数。需要把该表的索引 Region 一并纳入时，去掉 IS_INDEX = 0，保留子查询中的 Region 去重。

同样的查询可以用于 his_lab.charge_detail、emr_lab.emr_document_index、lis_lab.lab_request 和 hip_lab.hip_interface_message，分别查看收费明细、病历索引、检验申请和接口消息对应的 Region。

九、查看业务表的 Peer 分布

要查 outpatient_visit 的副本分布在哪些 TiKV 上，可以关联三个系统表。这里不限制 IS_INDEX，同时检查表数据和索引涉及的 Region。

SELECT
    s.STORE_ID,
    s.ADDRESS,
    COUNT(DISTINCT p.REGION_ID) AS peer_region_count,
    SUM(
        CASE
            WHEN p.IS_LEADER = 1 THEN 1
            ELSE 0
        END
    ) AS leader_region_count
FROM
(
    SELECT DISTINCT REGION_ID
    FROM information_schema.TIKV_REGION_STATUS
    WHERE DB_NAME = 'his_lab'
      AND TABLE_NAME = 'outpatient_visit'
) r
JOIN information_schema.TIKV_REGION_PEERS p
  ON r.REGION_ID = p.REGION_ID
JOIN information_schema.TIKV_STORE_STATUS s
  ON p.STORE_ID = s.STORE_ID
GROUP BY
    s.STORE_ID,
    s.ADDRESS
ORDER BY
    s.STORE_ID;

这组结果对应 355 个 Region、1065 个 Peer，Leader 合计 355 个，符合三 Store、三副本的设定。IS_LEADER = 1 表示该 Peer 是 Leader，IS_LEARNER = 1 表示 Learner。这条查询没有排除 Learner；若实际集群配置了 TiFlash 或其他 Learner，需要一并考虑。

子查询先去重，可以避免同一个 Region 的多条表、索引映射记录放大后续统计。查到的是副本当前所在的 Store，业务表没有固定绑定在某一台 TiKV 上。

十、检查 Peer 状态

SELECT
    STATUS,
    COUNT(*) AS peer_count
FROM information_schema.TIKV_REGION_PEERS
GROUP BY STATUS
ORDER BY STATUS;

需要看 Down 持续时间时，可以查看同表的 DOWN_SECONDS，单位为秒。

按前文 3762 个 Region、每个 Region 三副本计算，全部正常时的统计为：

这里数的是 Peer，每个 Region 会计入三次。调度过程中可以短暂出现少量 Pending Peer；数量持续偏高或长时间不下降时，再检查副本同步、节点负载和网络带宽。

十一、用 pd-ctl 检查异常 Region

Control 工具版本与集群保持一致。本文通过 TiUP 调用 v8.5.0 的 pd-ctl，检查缺副本、Down Peer 和 Pending Peer。

缺副本：

tiup ctl:v8.5.0 pd \
  -u http://10.20.10.21:2379 \
  region check miss-peer

存在 Down Peer 的 Region：

tiup ctl:v8.5.0 pd \
  -u http://10.20.10.21:2379 \
  region check down-peer

存在 Pending Peer 的 Region：

tiup ctl:v8.5.0 pd \
  -u http://10.20.10.21:2379 \
  region check pending-peer

三项检查没有发现对应异常时，各自返回：

{
  "count": 0,
  "regions": []
}

count 统计的是符合条件的 Region 数，不是异常 Peer 个数。同一个 Region 可能同时出现在多项检查中，不能把几项结果直接相加。region check extra-peer 则用于查找副本数超过期望数量的 Region。

十二、进程 Up 后仍要检查副本

TiUP 显示 TiKV 为 Up，不能证明所有 Region 的副本都已恢复。节点刚启动时，部分 Peer 可能仍在接收 Snapshot 或追赶 Raft Log。继续查看 Store 心跳和 Peer 状态。

miss-peer = 0 只表示 PD 当前没有记录副本数量不足的 Region。已有 Peer 仍可能处于 Down 或 Pending 状态，要与另外两项检查一起看。官方 PD_miss_peer_region_count 告警监控缺副本 Region 的数量，具体副本要求还需核对当前配置。

十三、确认副本配置

查看 PD 当前的副本配置：

tiup ctl:v8.5.0 pd \
  -u http://10.20.10.21:2379 \
  config show replication

主要字段如下，格式与官方命令示例一致：

{
  "max-replicas": 3,
  "location-labels": "",
  "isolation-level": "",
  "strictly-match-label": "false",
  "enable-placement-rules": "true"
}

max-replicas 默认是 3，对应一个 Leader 和两个 Follower。enable-placement-rules 在 v8.5 中默认开启。

再查看规则列表：

tiup ctl:v8.5.0 pd \
  -u http://10.20.10.21:2379 \
  config placement-rules show

只有一条默认规则时，max-replicas 等配置的修改会同步更新这条规则。存在多条规则时，各 Region 的副本要求以生效规则为准，不能只看全局的 max-replicas。

PD v8.5.0 在启用 Placement Rules 时，也按 Region 匹配到的规则计算期望副本数，再统计 miss-peer。

十四、Region 分布出现差异时查什么

假设看到下面的数量：

在本文三 Store、统一三副本的前提下，这种持续差异需要排查，不能当作正常的均衡误差。。核对副本规则、缺副本检查结果，以及是否正在分裂、合并、扩缩容或补副本，再看数据是否因心跳更新而短暂不同。

若集群的 Store 数多于副本数，再结合各 Store 的容量、AVAILABLE、REGION_SIZE 和 Leader 分布判断偏斜。同时核对热点 Region、节点 Label 和调度限制。PD 调度还会使用 Region Score、Leader Score 等信息，仅凭 Region 个数不足以决定如何调整。原因没有查清前，不能直接修改 leader-weight、region-weight、store limit 或 scheduler 参数。

十五、业务表的 Region 数增加

emr_document_index 的 Region 数比字典表多，并不意外。表数据和索引各自占用键空间，数据增长到一定规模后会触发 Region 分裂。看 Region 数是否持续异常增长，是否出现大量小 Region，以及 PD、TiKV 的负载是否同步升高。若同时出现 Pending Peer 积压，再检查副本同步。大量 Region 会增加 Raftstore 等模块的负担，但不能只凭某张表的 Region 数多就判断表设计有问题。

十六、Region 大小与磁盘容量

Region 大小并不固定，不能按“1000 个 Region，每个 256 MiB”直接算出表占用 250 GiB。前面的 APPROXIMATE_SIZE 汇总用于观察数据规模，物理空间还受到副本数、压缩和存储放大的影响。

容量规划时，需要同时参考 TABLE_STORAGE_STATS、Region 信息、Grafana 的 Store size 和实际磁盘增长趋势。TABLE_STORAGE_STATS.TABLE_SIZE 的单位为 MiB，也不应直接当成各节点文件系统占用的合计值。

十七、空间不足时不要只调高 low-space-ratio

把 low-space-ratio 从 0.8 改成 0.95，会推迟 PD 将 Store 判为低空间的时点。磁盘原来只剩 300 GiB，调整后仍然只有 300 GiB。先确认增长速度和文件占用，再评估是否增加 TiKV、扩充磁盘，或处理异常调度。

这个参数不会修改 TiKV_low_space 告警表达式中的 0.2，也不会修改集群 80% 空间使用率告警的表达式。PD_cluster_low_space 使用的是 PD 上报的低空间 Store 数，调整参数会影响这项统计。几种告警不能混为同一个阈值。

十八、结合 Grafana 看变化过程

SQL 留下当前的 Store、Region 和 Peer 状态，Grafana 用来查看变化时间和持续时长。主要看 TiKV-Details 中这些指标：

这些面板的位置和指标含义可对照 TiKV 监控指标详解。如果某台 TiKV 的 Available 突然下降，同时 I/O 使用率升高，把同一时间段的 Store size 和 Region 调度变化放在一起查。

十九、巡检记录表

按服务状态、Store 容量、Region 分布和 Peer 状态逐项记录。有异常再关联到具体业务表和 Region，保留发生时间及后续变化。