MySQL开源数据传输中间件架构设计实践

本文根据洪斌10月27日在「3306π」技术 Meetup - 武汉站现场演讲内容整理而成。

主要内容：

本次分享将介绍目前数据迁移、数据同步、数据消费，多IDC架构中数据复制技术所面临问题及现有的产品和方案，并分享新开源的能在异构数据存储之间提供高性能和强大复制功能的DTLE相关技术内容。

提纲：

1. MySQL Replication
2. DTLE核心场景
3. DTLE设计原则
4. DTLE相关介绍（架构/集群机制/拓扑结构/技术栈/功能/限制）
5. 同类对比
6. Demo演示
7. 云间同步案例

你们好，我今天分享的主题是关于爱可生在前不久开源的数据传输中间件DTLE，也可简称为DTS。爱可生做为一家以MySQL为主的技术服务公司，在咱们服务企业客户过程当中，常常会遇到各类数据同步的需求，能作数据同步的软件不少，但未能找到知足咱们全部需求的软件，因此咱们决定自研一款数据传输软件，结合咱们客户的需求场景作了DTLE，并选择在10月24号“程序员节”向社区开源。

今天主要是对DTLE的一些技术架构，跟你们分享。

1. MySQL Replication

MySQL如此受欢迎，其缘由和MySQL原生支持了 Replication密不可分。基于replication能力社区也是玩出了各类拓扑架构。

1.1 MySQL Replication架构

这张图对DBA们应该并不陌生，左边是MySQL主实例，右边是MySQL从实例，数据变动记录在binlog中。主实例的Dump线程，将binlog 事件经过网络推送给从实例。

从实例的IO线程将接收到事件写入本地relay log，SQL线程读取relay log bing进行回放执行，这是MySQL Replication的基本流程。

既然MySQL已经有了数据同步能力，那为什么还要作DTLE呢？

1.2 MySQL Replication的限制

- 筛选功能不足

MySQL Replication只能在库表级别作筛选，没法在行级别进行筛选。

- 数据落地，开销较大

MySQL Replication须要日志或数据落地，这会产生存储空间的开销。

- 灵活性较弱

没法支持较为复杂的复制拓扑结构，以及在跨网络边界不一样数据中心场景的。

- 应用场景多为高可用

MySQL replication更多以高可用、读写分离应用场景为主，利用开源工具实现Master failover以及读写分离架构。

2. DTLE的核心场景

MySQL Replication主要应用在数据全同步的场景。而对于DTLE主要解决如下场景：

- 异地多活

异地多活的场景一般创建在网络环境不佳的条件下，咱们经过数据压缩、加密、限速等方法，保障复制的可靠性、安全性、效率。解锁跨网络边际、双向同步等能力，在业务配合下，实现异地多活的。

- 数据汇聚分发

数据的汇聚和分发，须要支持到库、表、行这几个级别。好比：在业务垂直分库场景下可将前端多个分库实例汇总到实例中进行统计分析。数据行按不一样条件分发到下游节点，条件能够是简单的where条件，也但是简单函数表达式等。

- 数据订阅

数据订阅的场景是对MySQL binlog日志进行解析，将增量变化实时同步给Kafka消息队列，其余系统经过kafka订阅须要的数据。

- 在线数据迁移

在线数据迁移，要简化MySQL到MySQL或其余DB到MySQL的迁移过程，减小停机时间，目前还只支持MySQL间的迁移。首先抽取全量的数据，并获取增量起始的快照点，当全量回放完毕后，从增量起始点开始同步增量数据。

这对MySQL分布式架构的数据分片扩容特别有帮助，通常咱们将先预分片好的物理分片放在相同MySQL实例中，当数据量增加超过实例处理能力时，就须要讲分片迁移到新的实例节点，迁移过程确定但愿尽可能平滑不影响业务。DTLE能够配合咱们以前开源分布式中间件DBLE，进行在线扩容。

- 云间同步

公有云RDS用户会有一些上下云和云间迁移同步的需求，咱们测试了几家云厂商，针对云厂商自研的RDS for MySQL的特色，实现不一样云厂商的RDS之间进行数据同步。

3. DTLE设计原则

以上是DTLE主要的应用场景。软件设计DTLE力求两个基本原则：易用性与可靠性。

- 易用性

做为软件的使用者和开发者，咱们特别重视产品的使用体验，上手简单，易于部署是必须的，没有复杂的部署条件要求，没有外部依赖，安装配置步骤越简单越好，尽量符合使用者的操做习惯。

- 可靠性

可靠性也必不可少，咱们将DTLE的设计采用分布式的架构，具有扛单点风险和故障切换的能力。元数据信息保存在分布式一致性KV存储中，若是某工做节点或进程挂了，工做任务会转移至其余进程继续以前的断点处理数据同步，不影响服务连续性。

4. DTLE相关介绍

DTLE （Data-Transformation-le） 是爱可生10月24日在“程序员节”贡献开源社区的 CDC 工具，主要具有如下特色：

• 多种数据传输模式：支持链路压缩，支持同构传输和异构传输，支持跨网络边际的传输
• 多种数据处理理模式：支持库/表/行级别 数据过滤
• 多种数据通道模式：支持多对多的数据传输、支持回环传输
• 多种源/目标端：支持MySQL - MySQL的数据传输，支持MySQL - Kafka的数据传输
• 集群模式部署
• 提供可靠的元数据存储
• 可进行自动任务分配
• 支持自动故障转移

Github地址： https://github.com/actiontech...

4.1 DTLE架构

DTLE架构上包含两种角色的进程，Agent角色与Manager角色。Manager角色主要负责元数据信息存储，任务的接收和分发，Agent节点健康状态检测、故障转移。Agent主要负责数据读取，binlog解析，数据筛选、压缩、传输、回放等。

用户经过http协议访问Manager发布job，job是以json格式的配置项，里面定义了源数据库实例，目标数据库实例，须要复制的schema或table对象，数据的筛选条件等信息，任务提交后manager会分配给可用的agent进程，agent根据任务配置链接数据库实例，开始全量或增量的数据同步。

4.2 DTLE的集群机制

DTLE支持的多种拓扑结构，最简单的1对1同步，n对1的汇聚同步模式，1对n的数据分发同步模式。

在跨数据中心的场景，虚线框内是两个不一样的数据中心，DTLE部署在不一样的数据中心，DTLE负责本数据中心的数据读取或回放，DTLE将数据压缩后经过网络发送到对端，减小了对带宽的利用，适用于窄带宽的网络环境下。

在跨数据中心有多个实例之间须要数据同步，若是经过MySQL Replication须要创建多条链路通道，而经过DTLE能够在数据中心间创建一条通道同步多个实例的数据，网络策略配置更简单，也避免了MySQL服务对外暴露。

跨数据中心的双向同步能力，能够应用在数据中心双活的场景，但数据层自身还没法作冲突检测，须要在应用层来保障数据不会冲突。

4.4 DTLE技术栈

在DTLE的开发过程当中咱们借助了一些优秀的开源组件，来支撑起整个架构。

咱们选用的开发语言是Golang，它的好处是开发效率高，性能有保障，部署也方便，build后的二进制文件自带运行时环境，彻底不须要担忧软件依赖问题。

网上有许多优秀的Golang开源项目，Hashicorp公司就是其中一家以分布式应用见长的开源软件公司，他们开发了不少优秀的DevOps 基础设施组件，包括Vagrant、Packer 、 Terraform 、Serf 、Consul , Vault 和 Nomad 等，咱们使用了部分组件来构建DTLE。

nomad是一个集群管理器和调度器，咱们利用它来构建基础架构，解决的任务调度和集群管理的问题，在此基础上咱们开发所需的任务模板。

consul是一个分布式KV存储，nomad也集成了consul，咱们用它来作manager元数据信息存储。

serf是基于gossip协议的节点状态检测组件，可以快速检测到故障节点并踢出集群，主要用来解决agent节点的failover，若是某个agent节点不可用，这个节点就会被移出集群。

NATS是一款开源的轻量级消息系统组件，咱们在agent之间的数据传递使用了NATS。

以上是DTLE采用的开源组件。若是以前对这些组件由所了解，能够帮助理解DTLE的架构原理。

4.5 DTLE功能

DTLE的回放是支持binlog回放和SQL回放。binlog回放不须要对binlog事件进行转换，能够直接在MySQL中回放，精度高，但没法作数据转换或筛选。SQL回放是直接把binlog事件解析成SQL文本，能够进行数据的转换和筛选。

咱们模仿了MySQL MTS并行回放机制，基于MySQL 5.7的逻辑时钟模式，提升并行回放的效率。

自动建表，在数据迁移的场景下，目标端不须要事先创建表结构，只须要定义好job须要同步的对象，DTLE会自动建表并同步存量数据。

DTLE的所有功能总结：

• 集群式架构部署，支持故障转移
• binlog回放、SQL回放
• 仿MySQL MTS机制并行回放
• 支持增量断点续传
• 全量&增量同步
• 库级、表级、行级筛选
• 链路压缩、跨网络边际
• 自动建表
• 支持DDL

4.6 DTLE限制

• 仅支持 MySQL 5.6/5.7 版本
• 仅支持 InnoDB 引擎
• 仅支持如下字符集: latin一、latin二、gbk、utf八、utf8mb四、binary
• 仅支持binlog_format=row和binlog_row_image=full
• 源端和目标端lower_case_table_names配置必须保持⼀一致
• 必须开启 GTID
• 不支持 Trigger
• 仅支持MySQL认证方式 mysql_native_password, 暂不支持其余类型的

default_authentication_plugin

5. 同类对比

咱们选取了其余同类的开源软件debezium、streamsets、otter、DTLE，一块儿横向对比了相关特性。

- 全量/增量

debezium是支持全量增量的，对于streamsets和otter他们并无全量支持，只能作一些增量数据的支持，DTLE支持全量和增量。

- 元数据全局一致性

元数据信息的全局一致性是指在作全量数据迁移时如何得到增量数据起始的一致性位点。debezium是经过全局读锁或者快照读索实现的。streamsets和otter不支持全量，因此也不用考虑这个场景。

DTLE没有使用全局读锁，它在快照读的事务中读取存量数据，并在事务开启先后分别获取GTID。若是先后两个GTID是相等的，意味着在这个事务开启以后即便没有新的更新，后续能够今后GTID作增量同步。若是说先后两个GTID不等，事务将回滚，再重复上述流程。

- 数据过滤

在数据过滤方面，debezium支持库级， streamsets支持行级，otter能够自定义，DTLE是库、表、行三个等级都支持。

- 数据映射

数据映射上，debezium可以支持到表级的映射到普通表之间，原表、录入表可能不一样的表之间能够进行数据映射。一样streamsets也是，otter也能够灵活自定义。DTLE当前不支持数据映射，还在Roadmap中。

- 事务性

在MySQL binlog中一个事务可能包含多个event，咱们选择兼容在回放时保持其事务性。debezium能够作到源端的事物性，但不支持目标端的事务性。streamsets自己是没有事务性的，按event产生进行回放。otter不保持回放的事务性，为了提升入库的效率会进行合并操做。DTLE其实目标端和源端均可以保证事务性。

- GTID

DTLE会维护一份独立的GTID信息，主要来解决一些环形复制场景。其余三者都是不维护GTID信息的。

- 源端类型

源端类型，debezium支持的数据类型比较多，包括MySQL、Mongo、PostgreSQL、Oracle这几种都支持。MySQL是基于binlog，mongo是基于 Oplog，其余几种PG，SQL sever应该是经过CDC的方式，而非基于日志方式。streamsets支持许多中数据源，不详细展开了，otter主要是MySQL。DTLE还只是支持MySQL一种数据库。

- 目标端类型

debezium仅限于Kafka做为目标端。streamsets支持不少的目标端，再也不详细展开。otter支持 MySQL和Oracle，DTLE当前仅支持MySQL和Kafka。

- 部署方式

在部署方式上，debezium和streamsets都是单节点，otter是集群化的部署方式，DTLE支持单机和集群化部署。

6.DEMO演示

我这里准备了一些演示用例，主要演示如下几个场景，单向同步，表级汇聚，数据分发以及跨IDC双向复制。

Demo演示脚本： https://github.com/kevinbin/d...

感兴趣的同窗能够本身动手测试！

7.云间同步案例

咱们作了一个云间同步的测试，源端是阿里云RDS，目标端是京东云RDS，分别在华北区，和华东区。

使用TPCC的模型插入20个仓库，全部表加起来大概约10亿条记录。全量数据同步完耗时约5小时，平均是1000+ row/s，这里有关于该测试job的github地址，感兴趣的同窗能够本身测试下。

job连接：
https://gist.github.com/kevin...

将来咱们还会继续去作其余云厂商RDS的测试，以上是我今天的分享内容，谢谢你们！

咱们的开源数据传输中间件DTLE是具备专业团队维护和支持的，在使用过程当中遇到任何Bug和疑难问题均可以获得及时的修复和解答，欢迎加入DTLE技术交流群（852990221）！

PPT下载连接： github.com/actiontech/slides