Relay

作者：lan 本文为 DM 源码阅读系列文章的第五篇。 上篇文章 介绍了 dump 和 load 两个数据同步处理单元的设计实现，对核心 interface 实现、数据导入并发模型、数据导入暂停或中断的恢复进行了分析。 本篇文章将详细地介绍 DM 核心处理单元 Binlog replication，内容包含 binlog 读取、过滤、路由、转换，以及执行等逻辑。 文内涉及到 shard merge 相关逻辑功能，如 column mapping、shard DDL 同步处理，会在 shard merge 篇单独详细讲解，这里就不赘述了。 Binlog replication 处理流程 从上图可以大致了解到 Binlog replication 的逻辑处理流程，对应的 逻辑入口代码 。 从 relay log 或者 MySQL/MariaDB 读取 binlog events。 对 binlog events 进行处理转换（transformation），这里可以做三类操作： 操作 说明 Filter 根据 库/表同步黑白名单 对库/表进行过滤；根据 binlog event 类型过滤 。 Routing 根据 库/表 路由规则 对库/表名进行转换，用于合库合表。 Convert 将 binlog 转换为 job 对象 ，发送到 executor。 executor 对 job

Mysql主从基本原理，主要形式以及主从同步延迟原理 (读写分离)导致主库从库数据不一致问题的及解决方案 一、主从数据库的区别 从数据库(Slave)是主数据库的备份，当主数据库(Master)变化时从数据库要更新，这些数据库软件可以设计更新周期。这是提高信息安全的手段。主从数据库服务器不在一个地理位置上，当发生意外时数据库可以保存。 (1) 主从分工 其中Master负责写操作的负载，也就是说一切写的操作都在Master上进行，而读的操作则分摊到Slave上进行。这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在 10：1左右 ，也就是说大量的数据操作是集中在读的操作，这也就是为什么我们会有多个Slave的原因。但是为什么要分离读和写呢？熟悉DB的研发人员都知道，写操作涉及到锁的问题，不管是行锁还是表锁还是块锁，都是比较降低系统执行效率的事情。我们这样的分离是把写操作集中在一个节点上，而读操作其其他的N个节点上进行，从另一个方面有效的提高了读的效率，保证了系统的高可用性。 (2) 基本过程 1)、Mysql的主从同步就是当master（主库）发生数据变化的时候，会实时同步到slave（从库）。 2)、主从复制可以水平扩展数据库的负载能力，容错，高可用，数据备份。 3)、不管是delete、update、insert，还是创建函数

作者：张学程 本文为 DM 源码阅读系列文章的第二篇， 第一篇文章 简单介绍了 DM 源码阅读的目的和规划，以及 DM 的源码结构以及工具链。从本篇文章开始，我们会正式开始阅读 DM 的源码。 本篇文章主要介绍 DM 的整体架构，包括 DM 有哪些组件、各组件分别实现什么功能、组件之间交互的数据模型和 RPC 实现。 整体架构 通过上面的 DM 架构图，我们可以看出，除上下游数据库及 Prometheus 监控组件外，DM 自身有 DM-master、DM-worker 及 dmctl 这 3 个组件。其中，DM-master 负责管理和调度数据同步任务的各项操作，DM-worker 负责执行具体的数据同步任务，dmctl 提供用于管理 DM 集群与数据同步任务的各项命令。 DM-master DM-master 的入口代码在 cmd/dm-master/main.go ，其中主要操作包括： 调用 cfg.Parse 解析命令行参数与参数配置文件 调用 log.SetLevelByString 设置进程的 log 输出级别 调用 signal.Notify 注册系统 signal 通知，用于接受到指定信号时退出进程等 调用 server.Start 启动 RPC server，用于响应来自 dmctl 与 DM-worker 的请求 在上面的操作中，可以看出其中最关键的是步骤 4

作者：lan 本文为 DM 源码阅读系列文章的第三篇， 上篇文章 介绍了 DM 的整体架构，DM 组件 DM-master 和 DM-worker 的入口代码，以及两者之间的数据交互模型。本篇文章详细地介绍 DM 数据同步处理单元（DM-worker 内部用来同步数据的逻辑单元），包括数据同步处理单元实现了什么功能，数据同步流程、运行逻辑，以及数据同步处理单元的 interface 设计。 数据同步处理单元 从上图可以了解到目前 DM 包含 relay log、dump、load、binlog replication（sync） 4 个数据同步处理单元，涵盖了以下数据同步处理的功能： 处理单元 功能 relay log 持久化 MySQL/MariaDB Binlog 到磁盘 dump 从 MySQL/MariaDB dump 全量数据 load 加载全量数据到 TiDB cluster binlog replication（sync） 复制 relay log 存储的 Binlog 到 TiDB cluster 数据同步流程 Task 数据同步流程初始化操作步骤： DM-master 接收到 task， 将 task 拆分成 subtask 后 分发给对应的各个 DM-worker ； DM-worker 接收到 subtask 后 创建一个 subtask 对象 ，然后

作者：王相 本文为 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 集群的同一个表中

之前有遇到过主从数据库因为SQL语句问题导致同步报错，那如果同步中断之后，从哪里开始恢复呢？ 我们首先再来回顾一下主从同步的过程，手机码字不易，所以先copy一段。 一、主从原理 Replication 线程 Mysql的 Replication 是一个异步的复制过程，从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master 端。 要实现 MySQL 的Replication ，首先必须打开 Master 端的 Binary Log(mysql-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项，或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。 复制的基本过程如下 ： 1. Slave 上面的IO线程连接上 Master