一、问题提出 某测试环境, sql普遍跑得慢。 随便查看一条sql执行计划exec info中 tikv_task:{proc max:12.5s}, 扫表一次 TableRowIDScan 最大能达到12秒, 是不是tikv有什么问题？ 二、用grafana查看tikv状态 查看 TiKV-Details 面板下 Thread CPU 目录中的 [Unified read pool CPU] 图

前言 在另一篇《一个慢查询的基本分析》中仍遗留有一个问题, 即各个tikv主机之间出现交替的cpu波动(下图中), 是什么原因, 这在本篇中加以分析。 一、查看tikv图 tikv-1在08:53左右cpu下降, tikv-2在08:54左右cpu上升 初步判断，可能是有一些热点region，从tikv-1转到了tikv-2上，所以导致cpu消耗的迁移。 二、查找热点迁移的证据 在上一篇中已经定位

一、现象描述 在一个平平无奇的下午收到告警，登录到监控进行查看： Overview -> Tikv -> leader Overview -> Tikv -> region 通过观察 leader 和 region 的面板，我们发现某 TiKV 节点的 leader 被驱逐，leader 数量呈断崖式下降，最终 leader 被全部驱逐。但与此同时，该期间 region 数

一切开始的原因 由于数据开发的需要，我一度尝试将tidb 的使用范围更大话，同时目前大数据开发中，内存当做堆料，对于公司的开支也会与很大压力，那么就我就尝试将tikv 当做kafka 和redis 使用，本文章中将讲述开发的过程以及衍生品； row_id 是什么 也许你和我在尝试使用tikv的时候会感觉网上的资料好像都是不太对劲的样子，比如： https://tikv.github.io/clie

背景说明 1、store 状态是什么？ 首先，这里说的状态，是 store 的状态。即，这里不谈 region 的状态。 其次，这里的 store，可以简单类比为 TiKV 节点。 最后，这个状态是指整个集群中的store 状态，存储在 PD(ETCD)中的状态（可能跟 store 真实状态有偏差、不一致）。 分布式集群节点状态，是通过心跳来判断的。心跳依赖网络，所以网络异常导致无法准确判断节点状

借着这次社区 PCTA/PCTP/PCSD 免费考证的活动，看了不少的教程与优秀的社区文章，选了其中的一个点展开总结一下，也希望可以写成文章让大家给看看我这块的理解是不是存在偏差。 分布式事务是事务的一种，指的是事务的参与者，支持事务的服务器，参与事务的资源服务器，事务的管理者等角色分别位于不同的节点上。  通常我们用ACID来定义事务（ACID概念定义）。简单说一下这些概念以及TiDB数据库是怎

在之前发表的一篇文章中，介绍了TIKV分布式事务 ，这篇文章会接着上一篇文章，介绍一下分布式事务在节点出现异常时候的处理逻辑，与上一篇文档的目的一样，依然是希望分享出来让大家给看看我对这些逻辑的理解是不是存在偏差。 分布式事务的基本要素里，事务的原子性和一致性，在分布式集群中存在节点宕机的情况时，就无法保证，因此TIKV的分布式事务实现，使用了2PC。也就是之前介绍的prewrite和commit