前面文章介绍了 Pump server，接下来我们来介绍 Drainer server 的实现，Drainer server 的主要作用是从各个 Pump server 获取 binlog，按 commit timestamp 归并排序后解析 binlog 同步到不同的目标系统，对应的源码主要集中在 TiDB Binlog 仓库的 drainer/ 目录下。

作者介绍：陈霜，做个人吧队成员，PingCAP TiDB 研发工程师，做个人吧队参加了 TiDB Hackathon 2019，其项目「Manage many as one with SQL」获得了三等奖。

作者介绍：吕磊，Better 队成员、美团点评高级 DBA，Better 队参加了 TiDB Hackathon 2019，其项目「基于 TiDB Binlog 的 Fast-PITR」获得了最佳贡献奖。

从 70 年代关系型数据库进入历史舞台，很长一段时间它几乎是包打天下的选择。你很可能可以用一套数据库玩转所有业务，你也不需要一个连的工程师来维护她。哪怕你也许业务复杂，需要不同的数据库，但她们终究是还是数据库，温柔体贴。

在前两篇文章 TiKV 源码解析系列文章（十四）Coprocessor 概览、TiKV 源码解析系列文章（十五）表达式计算框架中，讲到了 TiDB 为了最大化利用分布式计算能力，会尽量将 Selection 算子、Aggregation 算子等算子下推到 TiKV 节点上，以及下推的表达式是如何在 TiKV 上做计算的。本文将在前两篇文章的基础上，介绍下推算...

作者介绍：孙晓光，知乎技术平台负责人，与薛宁（@Inke）、黄梦龙（@PingCAP）、冯博（@知乎）组队参加了 TiDB Hackathon 2019，他们的项目 TiSearch 获得了 CTO 特别奖。

作者介绍：代晓磊，现 360 商业化数据库运维专家，TiDB User Group Ambassador，负责整个智能商业业务线数据库运维，解决各种数据库疑难问题，推广 TiDB 等新开源数据库应用。

11 月初我们开启了一项社区新活动「TiDB 性能挑战赛」(Performance Challenge Program，简称 PCP)，这项积分赛将持续 3 个月，选手将完成一系列难度不同的任务，赢得相应的积分。目前赛程刚刚过去三分之一，已经取得了十分耀眼的阶段性成果：

曾在 Hacker News 上看到过一个 Oracle 工程师处理 bug 的 日常： 先花两周左右时间来理解 20 个参数如何通过神奇的组合引发 bug。 改了几行代码，尝试对 bug 进行修复，提交测试集群开始跑近百万个测试 case，通常要 20~30 小时。 运气好的话会有 100 多个 case 没过，有时候上千个也有可能，只好挑选几个来看，发现还...

在 上篇文章 中，我们主要介绍了 Pump Storage 是如何对 binlog 进行持久化存储、排序、配对的。在文中我们提到 binlog 的持久化键值存储主要是由 valueLog 组件完成的。同时，大家如果在上文点开 writeToValueLog 代码阅读的话会发现在其中还会使用一个 slowChaser 组件。slowChaser 组件主要用于避免在写 kv 环节中 Go...

SQL Server + .Net 是很多早期互联网企业的标配技术栈，虽然 TiDB 是兼容 MySQL 协议和生态的数据库，但是 TiDB 适用的业务场景是通用的。在开源新技术大行其道的今天，如何从 SQL Server 无缝迁移至 TiDB，汽车之家做了一个创新的示范。

众所周知，在对可用性要求极高的行业领域（比如金融、通信），分布式数据库需要跨地域的在多个数据中心之间建立容灾以及多活的系统架构，同时需要保持数据完整可用。但这种方式同时也带来了一些问题：

TiKV 是一个开源项目，我们一直都欢迎和感激开源社区对 TiKV 所作出的贡献。但我们之前对开源社区的合作主要是在代码审阅和散落在各种社交媒体的线下讨论，开发者并没有合适的途径去了解和影响 TiKV 的开发计划。怎么才能更好的帮助大家找到组织，更好地参与到 TiKV 的开发中来呢？我们的设想是搭建公开的平台，邀请对 T...

知乎技术平台团队负责人孙晓光有一个新的身份：开源分布式事务 Key-Value 数据库 TiKV项目的 Maintainer。Maintainer 是 TiDB/TiKV 开源社区的角色之一，是社区中较高级别的代码贡献者，项目的规划和设计者，拥有合并主干分支的权限。一般来说从开始贡献代码的 Contributor 成长为 Maintainer，最明显的变化是，对项目有...

在《十分钟成为 Contributor 系列 | 为 Cascades Planner 添加优化规则》中，我们简单介绍了 Cascades 的相关背景知识，本文将为大家深入介绍 TiDB 新的优化器——Cascades Planner 的框架及原理。

到今天为止，“成为 Contributor 系列”已经推出了 “支持 AST 还原为 SQL”，“为 TiKV 添加 built-in 函数”，“向量化表达式”等一列活动。这一次借着 TiDB 优化器重构的契机，我们将这个系列再向着数据库的核心前进一步，挑战一下「为 TiDB 的优化器增加优化规则」，带大家初步体验一下可以对查询的执行时间产生数量级影响的...

HAProxy 是一个使用 C 语言编写的自由及开放源代码软件，其提供高可用性、负载均衡，以及基于 TCP 和 HTTP 的应用程序代理。GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter 和 Tuenti 在内的知名网站，及亚马逊网络服务系统都在使用 HAProxy。

上一篇 《TiKV 源码解析系列文章（十四）Coprocessor 概览》讲到了 TiDB 为了最大化利用分布式计算能力，会尽量将 Selection 算子、聚合算子等算子下推到 TiKV 节点上。本文将继续介绍 Coprocessor 中表达式计算框架的源码架构，带大家看看 SQL 中的表达式是如何在 Coprocessor 中执行的。

本文由逊馁队的成员夏锐航同学主笔，介绍 Unified Thread Pool 项目的设计与实现过程。该项目实现了在 TiKV 中使用一个统一的自适应线程池处理读请求，能够显著提升性能，并可预测性地限制大查询对小请求的干扰，最终在 TiDB Hackathon 2019 中斩获一等奖。

上周我们推送了《让数据库运行在浏览器里？TiDB + WebAssembly 告诉你答案》，向大家展示了 TiDB-Wasm 的魅力：TiDB-Wasm 项目是 TiDB Hackathon 2019 中诞生的二等奖项目，实现了将 TiDB 编译成 Wasm 运行在浏览器里，让用户无需安装就可以使用 TiDB。本文由 Ti-Cool 队成员主笔，为大家详细介绍 TiDB-Wasm 设计与实现...

上周我们正式宣布了 TiDB 性能挑战赛。在赛季内，通过向 TiDB、TiKV、PD 贡献代码完成指定类别任务的方式，你可以获得相应的积分，最终你可以使用积分兑换礼品或奖金。在性能挑战赛中，你首先需要完成几道 Easy 的题目，积累一定量积分后，才能开始挑战 Medium / Hard 难度的题目。

Java 是当前非常流行的开发语言，很多 TiDB 用户的业务层都是使用 Java 开发的，本文将从 Java 数据库交互组件开发的角度出发，介绍各组件的推荐配置和推荐使用方式，希望能帮助 Java 开发者在使用 TiDB 时能更好的发挥数据库性能。

希望有一个数据库能够弹性扩展（分布式）到成百上千节点的规模，易于学习和理解，可以运行在私有云、公有云、Multi-Cloud、Kubernetes，也能够跑在嵌入式设备（比如树莓派）上，更酷的是也能够直接运行在浏览器里，而且不需要任何浏览器扩展（Extension），变成「口袋数据库」，就像那部电影《蚁人》。

如果说，人类进化动力源于挑战： 想突破速度，于是从太空飞行追逐到量子世界； 想追求稳定，于是在万变之中，求不变之道； 想打破繁复，于是用 1 台智能手机集成 N 种必需品，大道至简…… 那么，挑战充满不确定性的未来，就是 TiDB 这款开源产品的不断进化的内在基因——如何做到更好的性能、更强的稳定性、更惊人的易用性...

本文将简要介绍 TiKV Coprocessor 的基本原理，面向想要了解 TiKV 数据读取执行过程的同学，同时也面向想对该模块贡献代码的同学。阅读本文前，建议读者对 TiDB 整体架构有所了解，先阅读三篇文章了解 TiDB 技术内幕：说存储、说计算、谈调度。

TiDB Hackathon 2019 在 10 月 27 日完美收官！北京、上海、广州三地共 39 支队伍参赛，两天一夜的 Hacking Time，大家围绕着「Improve」主题，为 TiDB 性能、易用性、稳定性、功能等各方面做出提升，最终 6 支队伍瓜分了一、二、三等奖的 15 万元现金奖励，另有 4 支队伍分获最佳贡献奖、最佳创意奖、最具潜力奖和 CTO ...

作者：吴叶磊，PingCAP Cloud 工程师，毕业于浙江大学，热爱云原生与开源技术，开发并维护 kubectl-debug, aliyun-exporter 等开源项目，同时也是专注于云原生技术的博客作者，现负责 TiDB Operator 研发。曾负责酷家乐数据同步平台与容器监控系统的研发。

社区是一个开源项目的灵魂，随着 TiDB/TiKV 新的社区架构升级， TiKV 社区也计划逐步成立更多个 Special Interest Group（SIG ）吸引更多社区力量，一起来改进和完善 TiKV 项目。SIG  将围绕着特定的模块进行开发和维护工作，并对该模块代码的质量负责。

在 TiDB 的架构中，所有的数据按照 range 划分成一个个 Region 分布在多个 TiKV 实例上。随着数据的写入，一个集群中会产生上百万，甚至千万个 Region。而量变引起质变，单 TiKV 实例上过多的 Region 无疑会带来比较大的负担，进而影响整个集群的性能表现。

经过几年的发展，TiDB 社区已经逐渐成熟，但是随着社区的发展壮大，我们逐渐感受到了现在社区架构上的一些不足。经过一系列的思考和总结，我们决定升级和调整目前社区组织架构，引入更多的社区角色和社区组织，以便更好的激发社区活力，维护积极健康的社区环境。