一、问题提出 某测试环境, sql普遍跑得慢。 随便查看一条sql执行计划exec info中 tikv_task:{proc max:12.5s}, 扫表一次 TableRowIDScan 最大能达到12秒, 是不是tikv有什么问题？ 二、用grafana查看tikv状态 查看 TiKV-Det
2024-06-12
前言 在另一篇《一个慢查询的基本分析》中仍遗留有一个问题, 即各个tikv主机之间出现交替的cpu波动(下图中), 是什么原因, 这在本篇中加以分析。 一、查看tikv图 tikv-1在08:53左右cpu下降, tikv-2在08:54左右cpu上升 初步判断，可能是有一些热点region，从
2024-06-12
一、现象描述 在一个平平无奇的下午收到告警，登录到监控进行查看： Overview -> Tikv -> leader Overview -> Tikv -> region 通过观察 leader 和 region 的面板，我们发现某 TiKV 节点的 le
2024-06-11
一切开始的原因 由于数据开发的需要，我一度尝试将tidb 的使用范围更大话，同时目前大数据开发中，内存当做堆料，对于公司的开支也会与很大压力，那么就我就尝试将tikv 当做kafka 和redis 使用，本文章中将讲述开发的过程以及衍生品； row_id 是什么 也许你和我在尝试使用tikv的时候
2024-05-07
背景说明 1、store 状态是什么？ 首先，这里说的状态，是 store 的状态。即，这里不谈 region 的状态。 其次，这里的 store，可以简单类比为 TiKV 节点。 最后，这个状态是指整个集群中的store 状态，存储在 PD(ETCD)中的状态（可能跟 store 真实状态有偏差
2024-05-07
借着这次社区 PCTA/PCTP/PCSD 免费考证的活动，看了不少的教程与优秀的社区文章，选了其中的一个点展开总结一下，也希望可以写成文章让大家给看看我这块的理解是不是存在偏差。 分布式事务是事务的一种，指的是事务的参与者，支持事务的服务器，参与事务的资源服务器，事务的管理者等角色分别位于不同的节
2024-05-07
在之前发表的一篇文章中，介绍了TIKV分布式事务 ，这篇文章会接着上一篇文章，介绍一下分布式事务在节点出现异常时候的处理逻辑，与上一篇文档的目的一样，依然是希望分享出来让大家给看看我对这些逻辑的理解是不是存在偏差。 分布式事务的基本要素里，事务的原子性和一致性，在分布式集群中存在节点宕机的情况时，就
2024-05-07