TiDB MVCC 版本堆积相关原理及排查手段

导读

本文介绍了 TiDB 中 MVCC（多版本并发控制）机制的原理和相关排查手段。 TiDB 使用 MVCC 机制实现事务，在写入新数据时不会直接替换旧数据，而是保留旧数据的同时以时间戳区分版本。 当历史版本堆积过多时，会导致读写性能下降。 为了解决这个问题，TiDB 使用 Garbage Collection（GC）定期清理不再需要的旧数据。 文章从 TiDB 中 MVCC 版本的生成原理、数据写入过程和 TiDB 版本堆积常见排查手段等方面进行了详细介绍 。

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

如上所述，TiDB 底层使用的是单机存储引擎 rocksdb, 为了实现分布式事务接口，TiDB 又采用 MVCC 机制，基于 rocksdb 实现了高可用分布式存储引擎 TiKV。也就是当新写入（增删改）的数据覆盖到旧数据时，旧数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。当这些历史版本堆积越来越多时，就会引出一系列问题，最常见的便是读写变慢。TIDB 为了降低历史版本对性能的影响，会定期发起 Garbage Collection（GC） ( https://docs-archive.pingcap.com/zh/tidb/v7.2/garbage-collection-overview ) 清理不再需要的旧数据。

本文作为 TiDB GC 的前序文章，我们将详细介绍一下这些旧版本数据是如何堆积起来的，以及如何排查确认当前版本数据的堆积已经对集群性能构成了影响。

TiDB 中的 MVCC 版本的生成原理

  • 在 TIDB 层，我们最初收到的是一个关系型表的数据，TiDB 会将这个关系型表数据转化成 key-value，同时调用分布式事务接口，将 key-value 数据写入到 TiKV。
  • 在 TIKV 层，我们采用 MVCC 机制提供了分布式事务接口，最终所有的写入都会转化成一条 MVCC key-value 格式写入到 raftstore. 说到 MVCC 格式的 key-value, 无非就是每一个 key 上都有一个版本号，代表其提交的先后顺序。后面我们将这类格式的数据统一称为 MVCC key-value 对。
  • 在 raftstore 层，则最终将数据以 key-value 的形式，写入到 rocksdb 中。（注意，rocksdb（ https://docs.pingcap.com/tidb/stable/rocksdb-overview ） 本身基于 LSM 架构实现，所以它也有 MVCC 的概念，本文不做详细介绍，只对 TiDB 相关的内容点到为止）

数据写入过程

下面我们举个例子来详细讲讲在 TiDB 集群中，一个具体的写入过程。

当我们在 TiDB 中，执行以下 SQL 时：

insert into students set name="Bob",age=12,score=99

1.1 TiDB 侧 SQL table 转为 Key-Value

在 TiDB 层，我们有以上关系型表，上面这一行数据最终会变成三对 key-value（详细原理 https://book.tidb.io/session1/chapter3/tidb-kv-to-relation.html ），分别对应：

  • 主键对需要保证 key 唯一性：主键值 => 本行所有列数据
  • 唯一索引按 key 有序排列加速查询速度：name 列：唯一索引 => 主键
  • 非唯一索引按 key 有序排列提升查询性能：age 列：索引+主键 => 空值

1.2 TiKV 侧 MVCC 版本写入

在 TiKV 层，分布式事务接口在收到对应的 key-value 对后，会转成对应的 MVCC key-value 写入到 raftstore. 这里我们不展开分布式事务的具体实现逻辑，只用最简单的乐观锁模型（ TiDB 最佳实践系列（三）乐观锁事务 - 知乎 ）来举例。

Prewrite 接口完毕后：

其中锁 Lock CF（无版本号）如下:

  • t{table-id}r1=> start_ts,primary_key,ttl,PUT
  • t{table-id}i{indexID}_Bob=>start_ts,primary_key,ttl,PUT
  • t{table-id}i{indexID}_12_1=>start_ts,primary_key,ttl,PUT

数据 Default CF（mvcc 版本号 start_ts 在 key 的后缀里）如下：

  • t{table-id}r1_{start_ts}=> {Bob,12,99}
  • t{table-id}i{indexID}Bob{start_ts}=>1
  • t{table-id}i{indexID}_12_1{start_ts}=>null

具体实现中，会有一个优化，即当 value 值不是很大时，不会将数据单独放在 Default CF 里面（这里不展开具体介绍）。

Commit 接口调用完毕之后：

以主键对为例子，数据会发生如下变化：

Write CF 里面写入：

  • t{table_id}{commit_ts}=>start_ts

Lock CF 中对应 key 被删除（注意这里是 rocksdb 的一次删除，rocksdb 底层 LSM 也是 mvcc, 即删除对 rocksdb 也是写入一个新版本）：

  • t{table-id}r1=> start_ts,primary_key,ttl,PUT

综上，我们 以 主键所在 key 为例 ，展开 讲讲这个 key 随着增删改 mvcc 版本的变迁。

transaction 1: insert set id=1

transaction 2: update where id=1

update 之后，在 raftstore 里面留下的 mvcc 信息如下：

也就是说，update 并没有直接去更新上一次写入的内容，而是重新写了一份数据到底层。

transaction 3: delete id=1

那如果我们 delete id=1 的这一行数据呢？从下面我们可以看到，delete 也是通过写入一个新版本到底层。

综上，当我们对 id=1 依次做了 insert/update/delete 之后，对于 TiDB 客户端来说，这一行数据已经删除，但是对于存储底层来说，此时在 raftstore 层留下了以下多个 mvcc 版本。

可以看到，同一行数据会随着增删改的次数，积累越来越多的版本，这里历史的 mvcc 版本如果不及时清理，不光物理磁盘空间无法释放，更会对读写产生性能影响，所以我们需要 GC 来对这些旧版本数据进行回收。

TiDB 版本堆积常见排查手段

如前文所说，当 MVCC 版本出现堆积时，会对读写造成性能影响，此时，我们就需要对 GC 参数及状态进行判断，加速旧版本数据的回收，提升集群读写性能。

那么，在实际的业务场景中，如何判断我们的 MVCC 数据版本是否出现堆积，并对当前集群读写性能造成了影响呢？

2.1 Slow log 视角（具体慢 SQL 视角）

如前文所说，MVCC 版本堆积最直接的影响是读写变慢，所以我们从 slow log（ https://docs-archive.pingcap.com/zh/tidb/v7.2/identify-slow-queries ） 可以来排查 SQL 执行慢的原因是否是 mvcc 历史版本是否堆积过多。

tidb slow log: scan_detail: {total_process_keys: 1139428, total_process_keys_size: 433849330, total_keys: 1139434, rocksdb: {delete_skipped_count: 0, key_skipped_count: 2278852,....

上面摘取的一段日志是 slow log 里面，与 TiDB mvcc 版本数量有关的几个字段：

  • total_process_keys： 本次查询扫描的有用的用户 key 个数。不包含已删除的版本及 rocksdb 里面 tombstone 的版本
  • total_keys ：本次查询总共扫的 mvcc 版本个数

当 total_keys > total_process_keys*6 时，代表着查询范围内的平均每个 key 的 mvcc 版本是 6 以上，需要注意 GC 的相关参数是否合理，检查 GC 的状态是否正常。

Rocksdb 相关指标 （rocksdb 里面的 mvcc）：

  • delete_skipped_count: rocksdb 里面被标记为删除的 key. 当这个值比较大时，意味着 rocksdb 需要做 compaction 了
  • key_skipped_count（ https://github.com/facebook/rocksdb/blob/9f1c84ca471d8b1ad7be9f3eebfc2c7e07dfd7a7/include/rocksdb/perf_context.h#L84 ）： 实际读取过程中，rocksdb 读取迭代器中执行 next 的个数，代表着实际数据的读取量

下面我们举个例子来加深理解 slow log 里面的这些字段。（注意后续所有的例子 SQL 中，查询语句需要加上“explain analyze（ https://docs.pingcap.com/tidb/stable/sql-statement-explain-analyze ）” 才能看到具体的 mvcc 扫描详情）

Step 1：创建表结构

  • total_process_keys 是 0，因为它是一张空表。
  • total_keys =1 因为我们在查询之前并不知道这张表是否为空，需要拿出符合条件的第一个 MVCC 版本才能确认这条 mvcc 不是本表数据。

Step 2：插入一条 ID=1 的新数据

可以看到，插入完成后再查询时：

  • total_process_keys =1， 表中当前一共有一行数据（id=1）
  • total_keys =2, 扫完 id=1 的 key 后，还要往后扫一个 key 才能确认此表中已经没有数据

Step 3：更新 ID=1 的这行数据

更新完后再查询时：

  • total_process_keys =1 因为确实这张表中只有一行数据
  • total_keys = 3， 因为 id=1 这行数据有两个版本, 也就是本次更新增加了一个版本

Step 4：删除 ID=1 所在行

删除后执行查询时：

  • total_process_keys =0：删除了 id=1 这行数据后，表里面没有数据了
  • total_keys = 3+1：而删除 id=1 给这行数据增加了一个版本，所以 total_keys 比上一次多了 1 个

Step 5：插入一条 ID=2 的新数据

请尝试自行分析。

2.2 Grafana （集群）视角

因为 slow log 默认只记录 300 ms 以上的 SQL 读取细节，怎么看整个集群 mvcc 读取状态呢？这就需要我们从 grafana 级别来宏观分析了。

分布式事务 mvcc

监控地址：tikv-details->coprocessor-details-> Total Ops Details(TableScan/IndexScan)

如图所说：

Ops 具体分两种：

  • Table scan：代表着按 table 主键查询
  • Index scan：代表着按索引查询

具体监控值分两类：

  • processed_keys：代表查询后实际用户可见的 key 个数，与 slow-log 中的 total_processed_keys 概念一致
  • next/seek/..：代表本次查询在 TiKV 迭代器中每个指令的调用次数，一般 next 居多。所有指令总调用次数接近于 slow log 里面 total_keys

同样的，如果从上图中看到 processed_keys 所在的线如果远远小于 next, 则说明 mvcc 版本冗余对当前的读取已经构成性能影响。

Rocksdb 层看 MVCC

tikv-details->coprocessor->total rocksdb perf statistics：

这里 delete_skipped 主要是指 rocksdb 里面的 tombstone, 对应于 slow log 里面的 delete_skipped_count。

2.3 Region 视角（热点更新表视角）

在实际业务中，我们往往对某些 table 或者 table 中的某些行更新比较频繁，从集群角度看，就只有这些 table 涉及到的 region 的数据版本堆积比较严重。

同时 TiDB 在设计时，要求同一个 key 所在的所有 mvcc 版本数据只能落在一个 region 里面，所以如果 TiDB 中某一行数据更新过于频繁，会导致版本堆积过多而出现大 region 的情况（大于 1 G）。那么在遇到大 region 时，我们如何判断是否出现了这种情况呢？

tikv-ctl（ https://docs.pingcap.com/tidb/stable/tikv-control#print-some-properties-about-region ）工具提供了命令来查看具体 region 内 mvcc 数据的分布：

tiup ctl:v6.5.0 tikv --host 127.0.0.1:20160 region-properties -r  6493
Starting component `ctl`: /home/tidb/.tiup/components/ctl/v6.5.0/ctl tikv --host 127.0.0.1:20160 region-properties -r 6493
mvcc.min_ts: 442383585748713474
mvcc.max_ts: 442383589195644931
mvcc.num_rows: 410870
mvcc.num_puts: 410870
mvcc.num_deletes: 0
mvcc.num_versions: 410870
mvcc.max_row_versions: 1
writecf.num_entries: 410870
writecf.num_deletes: 0
writecf.num_files: 1
writecf.sst_files: 053983.sst
defaultcf.num_entries: 0
defaultcf.num_files: 0
defaultcf.sst_files: 
region.start_key: 7480000000000000ffe75f728000000000ff3f028e0000000000fa
region.end_key: 7480000000000000ffe75f728000000000ff454f410000000000fa
region.middle_key_by_approximate_size: 7480000000000000ffe75f728000000000ff42250e0000000000faf9dc567895dbfffe

其中我们重点关注 mvcc 为前缀的为 mvcc 相关数据：

  • mvcc.min_ts：这个 region 里面的所有版本中最小（最老）的 tso
  • mvcc.min_ts：本 region 数据中最新的 mvcc 版本 的 tso
  • mvcc.num_rows：用户可见的 key 个数（包含已删除的）= mvcc.num_put+mvcc.num_delete
  • mvcc.num_put：用户可见的 key 个数（不包含已删除的）
  • mvcc.num_delete：用户可见的已删除的 key 数
  • mvcc.num_version：用户可见的 mvcc 版本个数
  • mvcc.max_row_versions：本 region 中版本数最多的那个 key 拥有的版本数量

Rocksdb 的相关指标不详细展开，只需要关注到 *cf.num_deletes 比较高时，可以通过 手动 compaction ( https://docs.pingcap.com/tidb/stable/tikv-control#compact-data-of-each-tikv-manually )指定 CF 来解决。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：/a/525131.html

如若内容造成侵权/违法违规/事实不符，请联系我们进行投诉反馈qq邮箱809451989@qq.com，一经查实，立即删除！

相关文章

Golang | Leetcode Golang题解之第13题罗马数字转整数

Golang | Leetcode Golang题解之第13题罗马数字转整数

题目&#xff1a; 题解&#xff1a; var symbolValues map[byte]int{I: 1, V: 5, X: 10, L: 50, C: 100, D: 500, M: 1000}func romanToInt(s string) (ans int) {n : len(s)for i : range s {value : symbolValues[s[i]]if i < n-1 && value < symbolValues[s…
阅读更多...
MySQL - MySQL数据库的事务（一）

MySQL - MySQL数据库的事务（一）

1. 回顾一下MySQL运行时多个事务同时执行是什么场景 平时我们执行增删改的时候，无非就是从磁盘加载数据页到buffer pool的缓存页里去，对缓存页进行更新，同时记录下来undo log回滚日志和redo log重做日志，应该的是事务提交之后MySQL挂了恢复数据的场景，以及事务回滚的场景…
阅读更多...
AcWing 3. 完全背包问题

AcWing 3. 完全背包问题

解题思路 不过这种方式是有序的&#xff0c;而不是无序的。 相关代码 import java.util.Scanner;public class Main{static long f[] new long[1010];static int v[] new int[1010];static int w[] new int[1010];public static void main(String[] args){Scanner scan n…
阅读更多...
Windows Docker 部署 PostgreSQL 数据库

Windows Docker 部署 PostgreSQL 数据库

一、简介 PostgreSQL是一个功能强大且特性齐全的对象-关系型数据库管理系统&#xff0c;它以加州大学计算机系开发的POSTGRES为基础&#xff0c;并具备高度自由开源的特性。PostgreSQL支持大部分SQL标准&#xff0c;提供了复杂查询、外键、触发器、视图、事务完整性以及多版本…
阅读更多...
Android 11属性系统初始化流程

Android 11属性系统初始化流程

在init进程启动的第二阶段&#xff0c;调用PropertyInit 对属性系统进行初始化 int SecondStageMain(int argc, char** argv) {//省略PropertyInit();//省略 }PropertyInit函数在system\core\init\property_service.cpp 中实现 void PropertyInit() {//省略mkdir("/dev/…
阅读更多...
2024最新SpringCloud学习教程，Consul/Nacos/Feign/Sentinel/Gateway/Seata一网打尽

2024最新SpringCloud学习教程，Consul/Nacos/Feign/Sentinel/Gateway/Seata一网打尽

本文主要介绍了SpringCloud最新的应用技术&#xff0c;简单说明每类技术涉及的知识点&#xff0c;对应技术的学习资料、软件、可用代码和下载地址在文末给出。 文章目录 说明SpringCloud简介ConsulConsul简介使用示例 NacosNacos简介使用示例 负载均衡LoadBalancerLoadBalancer…
阅读更多...
链表实验.

链表实验.

#include<stdio.h> #include<stdlib.h>// 定义单链表节点结构体 struct Node {int data;struct Node* next; };struct Node* initList() {struct Node* list (struct Node*)malloc(sizeof(struct Node));list->data 0;list->next NULL;return list; }void…
阅读更多...
蚁剑修改特征性信息

蚁剑修改特征性信息

前言 我们首先得知道蚁剑的流量特征&#xff1a; 编码器和解码器的特征&#xff1a;蚁剑自带的编码器和解码器具有明显的特点&#xff0c;可以通过更改配置文件来达到流量加密的目的1。例如&#xff0c;蚁剑支持多种编码方式&#xff0c;如base64、chr、rot13等&#xff0c;这…
阅读更多...
海量智库 | ANY权限原理介绍

海量智库 | ANY权限原理介绍

ANY权限是Vastbase中的一种特殊的管理权限&#xff0c;用户能够通过ANY权限执行更广泛的操作&#xff0c;更加便利的管理数据库。 本文将为您介绍ANY权限管理的相关原理。 ANY权限管理相关解释 ANY权限管理&#xff0c;是对数据库内的某一类对象的所有实体进行特定的权限管理…
阅读更多...
【C++】继承总结

【C++】继承总结

一、前言 我们众所周知的C三大特性分别为&#xff1a;封装、继承、多态。 封装就是将接口实现统一化&#xff0c;隐藏那些不同的地方&#xff0c;在上层函数调用体现的方式一样&#xff0c;如各种容器的迭代器iterator&#xff0c;尽管底层实现的方式不同&#xff0c;但是在使用…
阅读更多...
C++数据结构与算法——贪心算法简单题

C++数据结构与算法——贪心算法简单题

C第二阶段——数据结构和算法&#xff0c;之前学过一点点数据结构&#xff0c;当时是基于Python来学习的&#xff0c;现在基于C查漏补缺&#xff0c;尤其是树的部分。这一部分计划一个月&#xff0c;主要利用代码随想录来学习&#xff0c;刷题使用力扣网站&#xff0c;不定时更…
阅读更多...
安全加固方面思路

安全加固方面思路

系统层面上的加固 备份重要配置文件&#xff1a;将一些重要的系统配置文件备份&#xff0c;包括 /etc/login.defs、/etc/security/limits.conf 等等。进行账号安全加固&#xff1a;修改密码安全策略&#xff0c;设置密码存在最长时间、密码长度、密码过期提醒等。 &#xff08…
阅读更多...
Linux设备模型统一：桥接硬件多样性与应用程序开发的关键

Linux设备模型统一：桥接硬件多样性与应用程序开发的关键

在Linux的宏大世界中&#xff0c;各种各样的硬件设备如星辰般繁多。从常见的USB设备到复杂的网络接口卡&#xff0c;从嵌入式设备到强大的服务器&#xff0c;Linux需要在这些差异极大的硬件上运行。这就引出了一个问题&#xff1a;Linux是如何统一这些不同硬件的设备模型的呢&a…
阅读更多...
Android 11 上的文件读写无权限问题

Android 11 上的文件读写无权限问题

Android 6以上需要动态申请读写权限&#xff0c;但是11以上动态申请了读写权限也是无效。并且手动给予权限没有该按钮。 如上图华为钱包有个所有文件权限、但是百度地图只有仅媒体权限&#xff0c;仅媒体权限&#xff08;动态申请读写权限&#xff09;给予后软件还是没法访问文…
阅读更多...
Linux中安装nacos

Linux中安装nacos

Linux中安装nacos 一、前言二、准备1、下载2、上传到服务器3、解压 三、配置1、备份配置文件2、导入sql3、修改前4、修改后 四、使用1、启动2、关闭 一、前言 最近国外的docker似乎是出什么问题&#xff0c;试过很多手段都拉不下 nacos 镜像&#xff0c;就打算在服务器装一下 …
阅读更多...
10. 【Android教程】网格布局 GridLayout

10. 【Android教程】网格布局 GridLayout

今天要学的布局和上一节的 TableLayout 很类似&#xff0c;是在 Android 4.0 版本引入的布局方式。GridLayout 很有意思&#xff0c;自从引入之后在 Android 开发圈有以下特点&#xff1a; 大部分的开发者可能都不知道有这个布局方式的存在&#xff1b;有些开发者虽然知道&…
阅读更多...
【智能算法】蛾群算法（MSA）原理及实现

【智能算法】蛾群算法（MSA）原理及实现

目录 1.背景2.算法原理2.1算法思想2.2算法过程 3.结果展示4.参考文献 1.背景 2017年&#xff0c;AAA Mohamed等人受到飞蛾趋光行为启发&#xff0c;提出了蛾群算法&#xff08;Moth Swarm Algorithm, MSA&#xff09;。 2.算法原理 2.1算法思想 MSA设待优化问题的可行解和适…
阅读更多...
Spring 如何优雅的灵活的Http重试

Spring 如何优雅的灵活的Http重试

1、背景说明 在互联网时代&#xff0c; 不同系统之间大多数是通过http调用&#xff0c;调用过程中会超时、异常等过种问题。为了保证业务稳定&#xff0c;http 重试是常用方案。下面列举几种方案。 2、Http重试方案介绍 2.1 传统方案 1、使用传统的递归调用&#xff0c;实现方…
阅读更多...
Java Lambda 表达式（详细）

Java Lambda 表达式（详细）

Java Lambda 表达式 Lambda 的发展史 Java Lambda 表达式是在 Java 8 版本中引入的重要特性&#xff0c;它描述了一种更简洁、更灵活的方式来处理函数式编程。 在 Java 8 之前&#xff0c;要实现函数式编程&#xff0c;需要通过匿名类实现接口的方式。这样的代码通常比较冗长…
阅读更多...
R语言数据可视化：基本绘图系统

R语言数据可视化：基本绘图系统

目录 plot函数 par函数 hist函数 boxplot函数 plot函数应用实战 R语言中有三大绘图系统包括基本绘图系统&#xff0c;Lattice绘图系统&#xff0c;ggplot2绘图系统 基本绘图系统 在R语言中&#xff0c;以下函数通常用于创建和定制图形&#xff1a; plot 函数&#xff…
阅读更多...
最新文章

Copyright @ 2022~2023