302 TiDB 高级系统管理 ： 数据库 OOM 问题诊断与处理之 TiKV

案例

block-cache

https://asktug.com/t/topic/63556/5

TiKV block cache 有哪些特性？

TiKV 使用了 RocksDB 的 Column Family (CF) 特性，KV 数据最终存储在默认 RocksDB 内部的 default、write、lock 3 个 CF 内。

• default CF 存储的是真正的数据，与其对应的参数位于 [rocksdb.defaultcf] 项中。
• write CF 存储的是数据的版本信息 (MVCC)、索引、小表相关的数据，相关的参数位于 [rocksdb.writecf] 项中。
• lock CF 存储的是锁信息，系统使用默认参数。
• Raft RocksDB 实例存储 Raft log。default CF 主要存储的是 Raft log，与其对应的参数位于 [raftdb.defaultcf] 项中。
• 所有 CF 共享一个 Block-cache，用于缓存数据块，加速 RocksDB 的读取速度。Block-cache 的大小通过参数 block-cache-size 控制，block-cache-size 越大，能够缓存的热点数据越多，对读取操作越有利，同时占用的系统内存也会越多。
• 每个 CF 有各自的 Write-buffer，大小通过 write-buffer-size 控制。

1.

TiKV Server 进程占用的内存包括以下哪几个部分？（请选3项）

A. Page Cache

B. RocksDB-kv Block Cache

C. SQL 查询的结果集在内存中的数据结构

D. RaftStore channel 以及 Apply channel 中的消息

2.

遇到 TiKV Server OOM 的情况后，通常从哪些方面进行排查？

A. 检查 storage.block-cache.capacity 参数设置是否过大，一般情况下为服务器内存的 45%

B. 查看 block-cache 的命中是否率低，如果偏低，那么需要确认 page cache 的占用情况

C. 检查是否出现了 gPRC 发送的速度跟不上 Coprocessor 的情况，TiKV-Details --> Coprocessor Overview --> Total Response Size 是否超过网卡的 network outbound 流量

D. 排查下当前集群环境中是否有返回结果集比较大的 SQL，并进行优化

Lesson 23：数据丢失快速恢复

https://learn.pingcap.com/learner/player/120012;id=120012;classroomId=9;rcoId=360009;courseDetailId=120005;learnerAttemptId=1641881375499

• 缺点：时效性 定期保留
• 
  

一篇文章带你玩转 TiDB 灾难恢复

https://asktug.com/t/topic/34246

从一个简单的Delete删数据场景谈TiDB数据库开发规范的重要性

https://asktug.com/t/topic/212885

系统变量tidb_gc_life_time和tidb_gc_run_interval可以控制GC的行为

删数据的原理解析

要搞清楚删除数据的原理，有几个东西你必须要知道：

• TiDB的GC和MVCC
• Region的概念以及Key的构成

https://asktug.com/t/topic/1350

2. MVCC多版本信息是如何保存的？

TiDB使用基于Percolator的事务模型，将一行数据抽象为default、write 和 lock 3 个 CF(column family)存储，其中:

• default CF存储的真正数据${key}_${start_ts} --> ${value}
• write CF存储数据的版本信息，commit_ts代表一行记录的真正版本${key}_${commit_ts}-->${start_ts}
• lock CF存放锁信息,提交中的事务会加lock，包含primary lock的位置${key}-->${start_ts,primary_key,..etc}

一个读取操作的过程如下:

事务begin时，从PD获取start_ts

读取key，先判断lock CF有没有锁，

如果:a. 有锁判断primary key状态是否超时若锁未超时，等待若锁已超时，根据primary key的状态rollback或commit残留事务

b. 无锁根据当前事务获取的start_ts对比数据的commit_ts(write CF)start_ts大于commit_ts，返回这行数据start_ts小于commit_ts，继续查找当前行的下一个(更早的)版本

根据步骤2得到的commit_ts，从default CF中获取真正的数据

TiDB GC 之原理浅析

https://asktug.com/t/topic/67760

GC

TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本，GC 的任务便是清理不再需要的旧数据。

Safepoint

每次 GC 时，首先 TiDB 会计算一个称为 Safepoint 的时间戳，接下来 TiDB 会在保证 Safepoint 之后的快照全部拥有正确数据的前提下，删除更早的过期数据。

GC 流程

每一轮 GC 分为以下三个步骤，这三个步骤在整个 GC 的流程中是串行执行。

如果一轮 GC 运行时间太久，上次 GC 还在前两个阶段，下轮 GC 又开始了，下一轮 GC 会忽略，GC Leader 会报 “there’s already a gc job running,skipped”：

• Resolve Locks：该阶段会对所有 Region 扫描 Safepoint 之前的锁，并清理这些锁。
• Delete Ranges：该阶段快速地删除由于 DROP TABLE/DROP INDEX 等操作产生的整区间的废弃数据。
• Do GC：该阶段每个 TiKV 节点将会各自扫描该节点上的数据，并对每一个 key 删除其不再需要的旧版本。

默认配置下，GC 每 10 分钟触发一次，每次 GC 会保留最近 10 分钟内的数据（ 即默认 GC Life Time 为 10 分钟，Safepoint 的计算方式为当前时间减去 GC Life Time ）。

为了使持续时间较长的事务能在超过 GC Life Time 之后仍然可以正常运行，Safepoint 不会超过正在执行中的事务的开始时间 (start_ts)。

update mysql.tidb set VARIABLE_VALUE="24h" where VARIABLE_NAME="tikv_gc_life_time";

tikv_gc_enable
控制是否启用 GC。
默认值：true

tikv_gc_run_interval
指定 GC 运行时间间隔。Duration 类型，使用 Go 的 Duration 字符串格式，如 “1h30m”，“15m” 等。
默认值：“10m0s”

tikv_gc_life_time
每次 GC 时，保留数据的时限。Duration 类型。每次 GC 时将以当前时间减去该配置的值作为 Safepoint。
默认值：“10m0s”

TiDB 的 GC 相关的配置存储于 mysql.tidb 系统表中，可以通过 SQL 语句对这些参数进行查询和更改：

select VARIABLE_NAME, VARIABLE_VALUE from mysql.tidb where VARIABLE_NAME like "tikv_gc%";+--------------------------+----------------------------------------------------------------------------------------------------+| VARIABLE_NAME | VARIABLE_VALUE |+--------------------------+----------------------------------------------------------------------------------------------------+| tikv_gc_leader_uuid | 5afd54a0ea40005 || tikv_gc_leader_desc | host:tidb-cluster-tidb-0, pid:215, start at 2019-07-15 11:09:14.029668932 +0000 UTC m=+0.463731223 || tikv_gc_leader_lease | 20190715-12:12:14 +0000 || tikv_gc_enable | true || tikv_gc_run_interval | 10m0s || tikv_gc_life_time | 10m0s || tikv_gc_last_run_time | 20190715-12:09:14 +0000 || tikv_gc_safe_point | 20190715-11:59:14 +0000 || tikv_gc_auto_concurrency | true || tikv_gc_mode | distributed |+--------------------------+---------------------------------------------------------

TiDB GC 之处理案例 & FAQ

https://asktug.com/t/topic/67764

https://docs.pingcap.com/zh/tidb/stable/dumpling-overview/#%E5%AF%BC%E5%87%BA%E5%A4%A7%E8%A7%84%E6%A8%A1%E6%95%B0%E6%8D%AE%E6%97%B6%E7%9A%84-tidb-gc-%E8%AE%BE%E7%BD%AE

假如导出的数据量非常大，可以提前调长 GC 时间，以避免因为导出过程中发生 GC 导致导出失败：

Copy

SET GLOBAL tidb_gc_life_time = '720h';

操作结束之后，再恢复 GC 时间为默认值 10m：

Copy

SET GLOBAL tidb_gc_life_time = '10m';

1.

下列关于 DDL 误操作，数据恢复方法描述正确的是？（ 请选 2 项 ）

A. Recover Table 适用于 Truncate Table 导致的数据误删除恢复

B. Recover Table 仅可用于 Drop Table 导致的数据误删除恢复

C. Flashback Table 适用于 Drop Table 以及 Truncate Table 导致的数据误删除恢复

D. Flashback Table 能够实现对一张表多次进行恢复操作

学生答案：、 A. Recover Table 适用于 Truncate Table 导致的数据误删除恢复 C. Flashback Table 适用于 Drop Table 以及 Truncate Table 导致的数据误删除恢复

FLASHBACK TABLE

在 TiDB 4.0 中，引入了 FLASHBACK TABLE 语法，其功能是在 Garbage Collection (GC) life time 时间内，可以用 FLASHBACK TABLE 语句来恢复被 DROP 或 TRUNCATE 删除的表以及数据。

可以使用系统变量 tidb_gc_life_time 配置数据的历史版本的保留时间（默认值是 10m0s）。可以使用以下 SQL 语句查询当前的 safePoint，

即 GC 已经清理到的时间点：

Copy

SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point';

只要被 DROP 或 TRUNCATE 删除的表是在 tikv_gc_safe_point 时间之后，都能用 FLASHBACK TABLE 语法来恢复。

语法

Copy

FLASHBACK TABLE table_name [TO other_table_name]

工作原理

TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。

所以，FLASHBACK TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录即可。恢复表的元信息可以用 TiDB 的快照读实现。具体的快照读内容可以参考读取历史数据文档。下面是 FLASHBACK TABLE t TO t1 的工作流程：

从 DDL History job 中查找 drop table 或者 truncate table 类型的操作，且操作的表名是 t 的第一个 DDL job，若没找到，则返回错误。

检查 DDL job 的开始时间，是否在 tikv_gc_safe_point 之前。如果是tikv_gc_safe_point 之前，说明被 DROP 或 TRUNCATE 删除的表已经被 GC 清理掉，返回错误。

用 DDL job 的开始时间作为 snapshot 读取历史数据，读取表的元信息。

删除 mysql.gc_delete_range 中和表 t 相关的 GC 任务。

将表的元信息中的 name 修改成 t1，并用该元信息新建一个表。注意：这里只是修改了表名，但是 table ID 不变，依旧是之前被删除的表 t 的 table ID。

可以发现，从表 t 被删除，到表 t 被 FLASHBACK 恢复到 t1，一直都是对表的元信息进行操作，而表的用户数据一直未被修改过。被恢复的表 t1 和之前被删除的表 t 的 table ID 相同，所以表 t1 才能读取表t 的用户数据。

注意：

不能用 FLASHBACK 多次恢复同一个被删除的表，因为 FLASHBACK 所恢复表的 table ID 还是被删除表的 table ID，

而 TiDB 要求所有还存在的表 table ID 必须全局唯一。

FLASHBACK TABLE 是通过快照读获取表的元信息后，再走一次类似于 CREATE TABLE 的建表流程，所以 FLASHBACK TABLE 实际上也是一种 DDL 操作。

正确答案：

B. Recover Table 仅可用于 Drop Table 导致的数据误删除恢复 、

C. Flashback Table 适用于 Drop Table 以及 Truncate Table 导致的数据误删除恢复

https://docs.pingcap.com/zh/tidb/stable/sql-statement-recover-table/#recover-table

RECOVER TABLE 的功能是恢复被删除的表及其数据。在 DROP TABLE 后，在 GC life time 时间内，可以用 RECOVER TABLE 语句恢复被删除的表以及其数据。

2.

基于 MVCC 数据恢复描述正确的是？（请选 3 项）

A. 要恢复的数据的时间点（safe point）未被 GC 掉，理论上历史数据均可恢复

B. set tidb_snapshot 的历史数据查询依赖 MVCC ，GC 数据保留策略

C. GC 参数 tidb_gc_life_time 设置的越久，则理论上允许恢复的数据时长越长

D. Recover Table，Flashback Table 仅依赖 MVCC，不依赖 GC 数据保留策略

正确答案：

A. 要恢复的数据的时间点（safe point）未被 GC 掉，理论上历史数据均可恢复 、

B. set tidb_snapshot 的历史数据查询依赖 MVCC ，GC 数据保留策略 、

C. GC 参数 tidb_gc_life_time 设置的越久，则理论上允许恢复的数据时长越长

一句话总结

请看这个文章 https://asktug.com/t/topic/67760

，第一篇为 『GC 原理浅析』，

第二篇为『GC 监控及日志解读』

而最后一篇则为『GC 处理案例

一个图片总结