Batch Dumping Statistics Delta

Background Recently, we have been tackling the challenge of supporting 3 million tables within a single TiDB cluster. One of the most significant hurdles we’ve faced is optimizing the performance of statistics collection. In its current implementation, TiDB gathers basic table information from all servers and consolidates it into a single system table. While functional, this approach becomes highly inefficient when managing millions of tables, consuming excessive CPU and taking a considerable amount of time....

December 14, 2024 · 8 min · Rustin liu

TiDB Analyze

December 14, 2024 · 0 min · Rustin liu

TiCDC, a tool for replicating the incremental data of TiDB

November 5, 2022 · 0 min · Rustin liu

Kafka: a Distributed Messaging System

May 11, 2022 · 0 min · Rustin liu

TiDB High Performance 课程实验 1

大家好,我是 Rustin. 最近开始做贵司推出的 TiDB High Performance 课程,所以开个课程实验记录的坑! 此博客在 GitHub 上公开发布. 如果您有任何问题或疑问,请在此处打开一个 issue. 简介 在高性能挑战赛的 文档 中找到第一节课的实验描述,实验需要分别下载和编译 TiDB, TiKV 和 PD, 并且需要修改 TiDB 源码让其在启动事务的时候,打印一句 hello transation 的日志。下面我就简单记录一下整个实验过程。 克隆源码并编译 需要分别克隆和编译 TiDB, TiKV 和 PD. 这三个库分别对应了 TiDB 中的计算,存储和调度三个层面。具体内容可以参考课程文档中对应的三篇文章。 编译 TiDB git clone https://github.com/Rustin170506/tidb 在编译之前,需要我们安装 make 工具,因为三个项目的 build 都是用 makefile 来组织的。查看 makefile 可以看到 .PHONY 中有个 server 的伪目标。内容如下: server: ifeq ($(TARGET), "") CGO_ENABLED=1 $(GOBUILD) $(RACE_FLAG) -ldflags '$(LDFLAGS) $(CHECK_FLAG)' -o bin/tidb-server tidb-server/main.go else CGO_ENABLED=1 $(GOBUILD) $(RACE_FLAG) -ldflags '$(LDFLAGS) $(CHECK_FLAG)' -o '$(TARGET)' tidb-server/main....

September 3, 2020 · 3 min · Rustin liu

Raft 领导人选举实现

大家好,我是 Rustin。最近在做 6.824 的实验 lab2,今天想写一篇文章记录一下前段时间做的 Raft 领导人选举机制的实现。 此博客在 GitHub 上公开发布. 如果您有任何问题或疑问,请在此处打开一个 issue。 简介 6.824 是 MIT 的分布式系统公开课,今年还有官方的视频资料放出。 目前也有国内的同学正在进行翻译工作,可以参考一下。 课程质量非常高,国内也有一些整理好的相关资料可以参考。 下面我就简单描述一下 Raft 领导人选举机制实现过程和一些踩过的坑,我会尽可能的聚焦在实现实验的细节上,因为我可能对 Raft 目前的理解也比较浅显。所以如果您对这篇文章感兴趣,请您先阅读论文和观看课程视频并尝试实现。 领导人选举规则分析 在 Raft 中分别有三种角色分别是:Leader, Follower 和 Candidate。在整个系统正常运行过程中,只会有一个 Leader 节点,其他的都是 Follower 节点。只有在需要重新选举的阶段,节点会尝试将自己转换为 Candidate,然后向所有的节点发出投票 RPC 消息展开选举。 我觉得而一个比较好的切入思路就是搞明白何时需要进行 Leader 的选举?我们阅读论文会发现主要有两种情况需要进行选举,一种就是当 Raft 集群启动之后开始第一次选举,另外一种就是 Leader 出现故障,无法使用心跳机制维持自己的统治, 导致选举超时机制触发,节点开始尝试新的一轮的选举(需要注意的是,选举有可能在一个 Term 中没有结果,那么就在下个 Term 中继续选举直到选出 Leader)。 搞清楚何时进行选举,我们再来看看选举的 RPC 请求和回复的数据结构: Request 参数 解释 term 候选人的任期号 candidateId 请求选票的候选人的 Id lastLogIndex 候选人的最后日志条目的索引值 lastLogTerm 候选人最后日志条目的任期号 Reply 返回值 解释 term 当前任期号,以便于候选人去更新自己的任期号 voteGranted 候选人赢得了此张选票时为真 从数据结构中我们可以看到能够影响到选举的主要有两个部分,一个是 Term,另外一个就是候选人的最后一条日志条目。那我们就尝试从这两点方面去消化和理解选举的规则:...

April 12, 2020 · 5 min · Rustin liu