TiDB Binlog

数据库存储了公司的数据，是公司的最重要资产之一。正确性和稳定性是数据库最重要的特性。测试团队之于 TiDB 是一个“破坏之王”的角色，团队的使命是炼成更高、更快、更强的 “无敌风火轮” 技能。在这篇文章里，我们介绍 PingCAP 测试团队（QA Team）是怎么工作的。 我们在做什么？ 我们测试团队是 TiDB 的“破坏者”，用各种手段尽早发现系统的 bug 是我们的工作。TiDB 有丰富的产品线，在这些产品线中，我们面对着不同的挑战。 首先，TiDB 内核稳定是整个系统稳定的基础和重中之重。TiDB 新版本的内核仍然处于高速发展的阶段。因此，测试要尽早发现新特性的正确性和稳定性问题，包括但不限于： 对 TiFlash 列存引擎，测试要构造破坏一致性保证的情况； 在 3.0 中，TiDB 增加了悲观事务，并支持了 RC 隔离级别。在 4.0 中，TiDB 支持了大事务，优化了 GC 的性能。这些特性的重要性不言而喻，必须进行严苛的、长时间的性能测试和稳定性测试； 挑战不断优化的 SQL 优化器和执行引擎，确保功能增强后的系统正确性和性能。例如 Index Merge、SQL Hint 和 SQL Plan Management 等特性； 验证调度稳定性的特性，例如 4.0 中的新热点调度器，构建不同的接近真实场景的负载，找出在这些负载下的系统不稳定的情况； TiKV

上篇文章 介绍了用于将 binlog 同步到 MySQL / TiDB 的 Loader package，本文往回退一步，介绍 Drainer 同步到不同下游的机制。 TiDB Binlog（github.com/pingcap/tidb-binlog） 用于收集 TiDB 的 binlog，并准实时同步给下游。 同步数据这一步重要操作由 Drainer 模块支持，它可以将 binlog 同步到 TiDB / MySQL / Kafka / File （增量备份）等下游组件。 对于 TiDB 和 MySQL 两种类型的下游组件，Drainer 会从 binlog 中还原出对应的 SQL 操作在下游直接执行； 对于 Kafka 和 File（增量备份）两种类型的下游组件，输出约定编码格式的 binlog。用户可以定制后续各种处理流程，如更新搜索引擎索引、清除缓存、增量备份等。TiDB Binlog 自带工具 Reparo 实现了将增量备份数据（下游类型为 File（增量备份））同步到 TiDB / MySQL 的功能。 本文将按以下几个小节介绍 Drainer 如何将收到的 binlog 同步到下游： Drainer Sync 模块：Drainer 通过 Sync 模块调度整个同步过程，所有的下游相关的同步逻辑统一封装成了 Syncer 接口。 恢复工具 Reparo （读音：reh

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者：黄佳豪 前面文章介绍了 Pump server，接下来我们来介绍 Drainer server 的实现，Drainer server 的主要作用是从各个 Pump server 获取 binlog，按 commit timestamp 归并排序后解析 binlog 同步到不同的目标系统，对应的源码主要集中在 TiDB Binlog 仓库的 drainer/ 目录下。 启动 Drainer Server Drainer server 的启动逻辑主要实现在两个函数中： NewServer 和 (*Server).Start() 。 NewServer 根据传入的配置项创建 Server 实例，初始化 Server 运行所需的字段。其中重要字段的说明如下： metrics: MetricClient ，用于定时向 Prometheus Pushgateway 推送 drainer 运行中的各项参数指标。 cp: checkpoint ，用于保存 drainer 已经成功输出到目标系统的 binlog 的 commit timestamp。drainer 在重启时会从 checkpoint 记录的 commit timestamp 开始同步 binlog。 collector: collector ，用于收集全部

作者：Chunzhu Li 在 上篇文章 中，我们主要介绍了 Pump Storage 是如何对 binlog 进行持久化存储、排序、配对的。在文中我们提到 binlog 的持久化键值存储主要是由 valueLog 组件完成的。同时，大家如果在上文点开 writeToValueLog 代码阅读的话会发现在其中还会使用一个 slowChaser 组件。 slowChaser 组件主要用于避免在写 kv 环节中 GoLevelDB 写入太慢甚至出现 write paused 时影响 Pump Storage 的执行效率的问题。 接下来，本篇文章重点介绍 valueLog 与 slowChaser 这两个组件。 valueLog valueLog 组件的代码位于 pump/storage/vlog.go 中，主要作用是管理磁盘中的所有存放 Binlog Event 的 logFile 文件。Pump 本地 GoLevelDB 中存储的 key value 中，key 用 Binlog 的 StartTs/CommitTs 拼成，value 则只是一个索引，指向 valueLog 中的一条 Binlog 记录。 valueLog 的结构体定义如下所示： type valueLog struct { buf *bytes.Buffer // buf to write to the

作者：Chunzhu Li 在 上篇文章 中，我们主要介绍了 Pump Storage 是如何对 binlog 进行持久化存储、排序、配对的。在文中我们提到 binlog 的持久化键值存储主要是由 valueLog 组件完成的。同时，大家如果在上文点开 writeToValueLog 代码阅读的话会发现在其中还会使用一个 slowChaser 组件。 slowChaser 组件主要用于避免在写 kv 环节中 GoLevelDB 写入太慢甚至出现 write paused 时影响 Pump Storage 的执行效率的问题。 接下来，本篇文章重点介绍 valueLog 与 slowChaser 这两个组件。 valueLog valueLog 组件的代码位于 pump/storage/vlog.go 中，主要作用是管理磁盘中的所有存放 Binlog Event 的 logFile 文件。Pump 本地 GoLevelDB 中存储的 key value 中，key 用 Binlog 的 StartTs/CommitTs 拼成，value 则只是一个索引，指向 valueLog 中的一条 Binlog 记录。 valueLog 的结构体定义如下所示： type valueLog struct { buf *bytes.Buffer // buf to write to the

作者：Chunzhu Li 在 上篇文章 中，我们主要介绍了 Pump Storage 是如何对 binlog 进行持久化存储、排序、配对的。在文中我们提到 binlog 的持久化键值存储主要是由 valueLog 组件完成的。同时，大家如果在上文点开 writeToValueLog 代码阅读的话会发现在其中还会使用一个 slowChaser 组件。 slowChaser 组件主要用于避免在写 kv 环节中 GoLevelDB 写入太慢甚至出现 write paused 时影响 Pump Storage 的执行效率的问题。 接下来，本篇文章重点介绍 valueLog 与 slowChaser 这两个组件。 valueLog valueLog 组件的代码位于 pump/storage/vlog.go 中，主要作用是管理磁盘中的所有存放 Binlog Event 的 logFile 文件。Pump 本地 GoLevelDB 中存储的 key value 中，key 用 Binlog 的 StartTs/CommitTs 拼成，value 则只是一个索引，指向 valueLog 中的一条 Binlog 记录。 valueLog 的结构体定义如下所示： type valueLog struct { buf *bytes.Buffer // buf to write to the

作者： satoru 在 上篇文章 中，我们介绍了 TiDB 如何通过 Pump client 将 binlog 发往 Pump，本文将继续介绍 Pump server 的实现，对应的源码主要集中在 TiDB Binlog 仓库的 pump/server.go 文件中。 启动 Pump Server Server 的启动主要由两个函数实现： NewServer 和 (*Server).Start 。 NewServer 依照传入的配置项创建 Server 实例，初始化 Server 运行所必需的字段，以下简单说明部分重要字段： metrics ：一个 MetricClient ，用于定时向 Prometheus Pushgateway 推送 metrics。 clusterID ：每个 TiDB 集群都有一个 ID，连接到同一个 TiDB 集群的服务可以通过这个 ID 识别其他服务是否属于同个集群。 pdCli ： PD Client，用于注册、发现服务，获取 Timestamp Oracle。 tiStore ：用于连接 TiDB storage engine，在这里主要用于查询事务相关的信息（可以通过 TiDB 中的对应 interface 描述 了解它的功能）。 storage ：Pump 的存储实现，从 TiDB 发过来的 binlog 就是通过它保存的

作者：王相 本文为 DM 源码阅读系列文章的第七篇，在 上篇文章 中我们介绍了 relay log 的实现，主要包括 relay log 目录结构定义、relay log 数据的处理流程、主从切换支持、relay log 的读取等逻辑。 本篇文章我们将会对 DM 的定制化数据同步功能进行详细的讲解。 在一般的数据同步中，上下游的数据是一一对应的，即上下游的库名、表名、列名以及每一列的值都是相同的，但是很多用户因为业务的原因希望 DM 在同步数据到 TiDB 时进行一些定制化的转化。下面我们将主要介绍数据同步定制化中的库表路由（Table routing）、黑白名单（Black & white table lists）、列值转化（Column mapping）、binlog 过滤（Binlog event filter）四个主要功能的实现。值得注意的是，由于其他一些工具（例如 TiDB Lightning 和 TiDB Binlog）也需要类似的功能，所以这四个功能都以 package 的形式维护在 tidb-tools 项目下，这样方便使用和维护。 库表路由（ Table routing ） 库表路由顾名思义就是对库名和表名根据一定的路由规则进行转换。比如用户在上游多个 MySQL 实例或者 schema 有多个逻辑上相同的表，需要把这些表的数据同步到 TiDB 集群的同一个表中

作者：赵一霖 在 上篇文章 中，我们主要介绍了 Pump Server 的上线过程、gRPC API 实现、以及下线过程和相关辅助机制，其中反复提到了 Pump Storage 这个实体。本文就将介绍 Pump Storage 的实现，其主要代码在 pump/storage 文件夹中。 Pump Storage 由 Pump Server 调用，主要负责 binlog 的持久化存储，同时兼顾排序、配对等功能，下面我们由 Storage 接口开始了解 Pump Storage 的实现。 Storage interface Storage 接口 定义了 Pump Storage 对外暴露的操作，其中比较重要的是 WriteBinlog 、 GC 和 PullCommitBinlog 函数，我们将在下文具体介绍。Storage 的接口定义如下： type Storage interface { // WriteBinlog 写入 binlog 数据到 Storage WriteBinlog(binlog *pb.Binlog) error // GC 清理 tso 小于指定 ts 的 binlog GC(ts int64) // GetGCTS 返回最近一次触发 GC 指定的 ts GetGCTS() int64 // AllMatched 返回是否所有的 P-binlog 都和 C

作者：satoru TiDB Binlog 架构简介 TiDB Binlog 主要由 Pump 和 Drainer 两部分组成，其中 Pump 负责存储 TiDB 产生的 binlog 并向 Drainer 提供按时间戳查询和读取 binlog 的服务，Drainer 负责将获取后的 binlog 合并排序再以合适的格式保存到对接的下游组件。 在《 TiDB Binlog 架构演进与实现原理 》一文中，我们对 TiDB Binlog 整体架构有更详细的说明，建议先行阅读该文。 相关源码仓库 TiDB Binlog 的实现主要分布在 tidb-tools 和 tidb-binlog 两个源码仓库中，我们先介绍一下这两个源码仓库中的关键目录。 1. tidb-tools Repo: https://github.com/pingcap/tidb-tools/ 这个仓库除了 TiDB Binlog 还有其他工具的组件，在这里与 TiDB Binlog 关系最密切的是 tidb-binlog/pump_client 这个 package。 pump_client 实现了 Pump 的客户端接口，当 binlog 功能开启时，TiDB 使用它来给 pump 发送 binlog 。 2. tidb-binlog Repo: https://github.com/pingcap/tidb