作者：陈梓立（tison）
欢迎来到新一期的 This Week on TiDB 栏目！TiDB 是一个开源的 MySQL 协议兼容的分布式数据库，支持混合事务和分析处理（ HTAP ）。这个栏目是 TiDB 开发进展和社区新闻的非官方周刊窗口，如果你想将自己看到或者正在做的工作也通过这个窗口发布，欢迎私信联系我或者在 weekly 仓库中提出。如果你有意了解或加入 TiDB 社区，TiDB 社区也非常欢迎贡献者。
Contribute to TiDBpingcap.github.iotisonkun/weeklygithub.com
本周是 v5.2 开发的第三周，我们首先顺着已经发布的开发计划看一下功能开发进展吧。
TiDB v5.2 Planning
Support spill HashAgg to diskgithub.com
@wshwsh12 主导的 HashAgg 中间数据 spill 到磁盘的设计文档评审和功能代码开发已经完成。不过功能代码开发的 PR 只包含了一个端到端的 SQL 测试，这项工作目前还有一个测试子任务有待完成，但是目前 issue 上仍未体现具体的测试计划。
Tracking issue for restructure testsgithub.com
为了改善单元测试的撰写体验和全面回顾 TiDB 的测试代码，Restructure Tests 提案正在进行当中。本周这项工作吸引了 @OAkaLala @Ranxy @ateb14 @evilbinary @jyz0309 @xxchan 等多位贡献者参与。
如上周所述，从测试代码入手是一种带着明确目标切入软件代码的捷径。目前，TiDB 的测试覆盖率比起其他顶级数据库软件仍有不足，在开发新功能时薄弱的新测试用例就是测试框架的易用性缺失和代码可测试性不足带来的后果之一。测试绝对不是简单或者重复的工作，测试是生产代码的第一个用户，从测试可以窥见生产代码的组织逻辑和质量。
@tiancaiamao 在 tracking issue 下创建了一个子问题，提出测试框架能否支持超时设置，就是对测试能力提出的一个挑战。
欢迎想要了解 TiDB 却找不到切入点的开发者，对 Golang 项目测试或数据库测试有经验的开发者，参与到这项工作中来，提升 TiDB 作为一个分布式数据库的软件质量。
Tracking issue for SPM enhancementgithub.com
这项工作由 @eurekaka 主导。我承认我花了一段时间才理解 SPM 是 SQL Plan Management 的缩写，缩写真是太难了，甚至 TiDB 的代码搜索都搜不出来 SPM 的定义。
关于查询优化我不甚了解，只好贴上 tracking issue 以供各位感兴趣的读者翻阅。不过值得一提的是，这里面的 enhancement issue 不少创建于 2020 年，可以说都是一些长时间待解决的问题了。
Tracking issue for heuristic rules enhancement for index selectiongithub.com
这项工作由 @winoros 主导。直接看起来是索引选择性的启发式规则改进，同样是查询优化范畴的内容。目前暂未看到相应的设计文档，所以也只能猜测它要干什么。如果有对此感兴趣的同学，欢迎直接到 tracking issue 下提问。
对于 feature owner 来说，有人关注他的工作是很好的正反馈；同时有人提问也是把 tracking issue 和相应的技术决定公开讨论的拉动力之一。
Tracking issue for Cardinality Estimation Enhancementgithub.com
这项工作由 @qw4990 和 @time-and-fate 主导，@tangwz 也对其内容表示了兴趣，但尚未得到回复。
直接看起来是关于基数消除的优化，同样是查询优化范畴的内容。类似的，尚未看到相应的设计文档，所以也只能猜测它要干什么。
其他 SQL Engine 相关的工作暂时还没仔细关注到，等到下一期一起做一个信息更新吧！
TiKV v5.2 Planning
raftstore: support asynchronous write iogithub.com
Async IO 旨在改善 TiKV RaftStore 的写入性能，这项工作由 @gengliqi 主导实现，@BusyJay @NingLin-P @hicqu @innerr 等开发者参与代码评审。这项改动依赖于 raft-rs 算法层面对 fsync 要求的放松，随后改动 TiKV 代码相应的同步逻辑变成异步写入。
这项工作开始于 v5.2 之前，仅有的中文设计文档在几位开发者之间流传，目前的两个 PR 动辄几十个文件几十个开发者讨论的历史几乎是不可理解的。鉴于 Raft 算法对细节的要求，和存储系统对底层操作了解的前提，建议希望了解这项优化细节的同学直接在 issue 或 PR 下进行技术讨论。有了实际技术讨论的需求，开发者们也许就会发现，把设计文档翻译成英文发布是最简单的交流方式。
Tracking issue of TiKV disk full · Issue #10537 · tikv/tikvgithub.com
这项工作由 @tier-cap 主导，旨在使得 TiKV 在磁盘满时仍能保持部分功能，而不是直接 panic 挂掉，Tracking issue 上简述了工作目标。
实际上，基础软件保持可用或者说在应用层面捕获异常是非常重要的一个能力。Linus 在讨论 Linux 内核中采用 Rust 语言编写代码时，一个主要担忧就是内存分配失败时不应该 panic 挂掉，而是给出一个可以处理的异常。
Support online recovery for Raft majority failuregithub.com
这项工作由 @Connor1996 主导，主要是解决在 Raft 集群多数节点下线的情况下如何恢复集群服务的问题。
如同 tracking issue 的 Spec 一节中提到的，这种情况下所有的解决方案都不能保证数据的完整性。但是线上服务不可用往往是更不能接受的情况，这项工作旨在对无法保证的完整性的不同取舍给到用户选择，以针对各自特定的场景采取损害最小的方式恢复集群。
Introduce slow node detecting mechanismgithub.com
这项工作由 @5kbpers 主导，旨在及时发现 TiKV 集群中的慢节点。
TiKV 在生产环境的部署越来越庞大，单一集群包含的 TiKV 节点数越来越多。随着集群的扩展，节点故障导致的集群不稳定的概率也会提升。其中单个或若干个故障节点的出现会使得集群整体处于不稳定的状态，如何尽快发现故障节点，及时告警并通知运维人员介入摘除，是 TiKV 可扩展性的一个必然要求。这项工作就初步提供了这样的能力。
Weighted Multidimensional Hot Scheduler Tasklist · Issue #3869 · tikv/pdgithub.com
这项工作由 @Yisaer 和 @lhy1024 主导，目标是提供多维度的热点调度策略。
目前，PD 作为 TiKV 集群的大脑，主要的热点调度维度是存储占用和 key 的数量，对于高 CPU 热点的调度表现不佳。这项工作旨在提供一种通用的多维度的热点调度策略，以支持目前遇到的高 CPU 热点的调度问题，并可以方便地扩展其他的新热点调度策略。
Tracking issue for Region Label Feature
这项工作由 @disksing @rleungx @JmPotato 主导，目标是提供通过标签来选择 Region 的机制。熟悉 Kubernetes 类似机制的同学对这样的需求应该不陌生。
目前，这项工作实现以后主要的应用场景是用于 region 合并的过程，具体细节从 tracking issue 中无法得知。
Forum
在开发者论坛上，本周也有不少 TiDB 及其周边生态的新情报。
Proposal: Merge BR repo into TiDBinternals.tidb.io
@3pointer 抛出了一个简短的提案，旨在解决 TiDB 及其数据备份和恢复工具 BR 长期以来的循环引用问题。
实话说，任何遇到过这个问题的人应该都对它印象深刻。循环引用堪称程序设计领域最令人头疼的问题，为了在循环引用的环里做一个改动，需要小心翼翼地按照既定步骤按照顺序改动，往往一个改动就要求三到四个不同 repo 之间严格有序的操作。万一改错了，回滚更是一场噩梦。
TiDB 在历史上产生了若干开发者深恶痛绝的循环引用。除了 repo 内部为了绕过循环引用引入的接口，及其后来由于 Golang 惰性实现接口导致接口未实现带来的错误和性能损耗，TiDB 和 BR 的循环引用绝对是 repo 间循环引用的典型案例。
@3pointer 在提案中介绍了解决这一问题的办法，会带来部分 import 路径的破坏性变更。所以，如果你的代码依赖了 BR 或 TiDB 中相应的代码，可以关注这个提案，并报告具体的使用场景，避免 TiDB 在解决自己陈年旧疾的时候不小心误伤了用户的生产环境。
TiKV X JuiceFS On The Gointernals.tidb.io
JuiceFS 采用 TiKV 作为自己元数据存储的计划有了新的进展。在第一个功能性 PR 合并后，JuiceFS 团队针对 TiKV 在此场景下的性能做了一轮测试。测试结果可以通过上面链接卡片跳转查看。
HugeGraph Database X TiKVinternals.tidb.io
HugeGraph 是一个图数据库，目前正在考虑采用 TiKV 作为自己的数据存储后端。这个提案概述了项目的背景和技术方案，对图数据库或 TiKV 的应用场景感兴趣的同学不妨一看。
Some questions about TiKV Coprocessorinternals.tidb.io
@mapleFU 提问了关于 TiKV 协处理器相关的问题，领域专家 @skyzh 快速地给予了回答。
欢迎对 TiDB & TiKV 功能设计和代码实现有疑问的同学在 TiDB Internals 论坛上提出自己的问题。
How to walk through a Plan gracefully?internals.tidb.io
@leiysky 想知道 TiDB 是否有遍历 Plan 的框架代码。目前这个提问有三个赞，但是还没有一个回答，看来是一个缺失的开发者都想要的功能。
如果你知道 TiDB 怎么实现这个功能，或者对实现这个功能有设计或实现上的想法，欢迎在这个帖子下回复。
小伙伴们注意啦～
为了可以给 TiDB 社区 的小伙伴提供更加好的体验，我们开通认证入口啦~完成认证，即可获得**“加急**”处理问题权限，加快问题响应速度：https://tidb.io/account/organization/new
TiDB 社区精美周边领取指南： TiDB 帆布包； TiDB 解压魔方； TiDB 纪念款金属芯签字笔1支 ；TiDB 三合一充电线，任一款周边 【人人有份】TiDB 社区精美周边获取指南，人手一份