Mysql数据实时同步实践 _Mysql数据

背景MySQL由于自身简单、高效、可靠的特点，成为小米内部使用最广泛的数据库，但是当数据量达到千万/亿级别的时候，MySQL的相关操作会变的非常迟缓；如果这时还有实时BI展示的需求，对于mysql来说是一种灾难。
为了解决sql查询慢，查不了的业务痛点，我们探索出一套完整的实时同步，即席查询的解决方案，本文主要从实时同步的角度介绍相关工作。
早期业务借助Sqoop将Mysql中的数据同步到Hive来进行数据分析，使用过程中也带来了一些问题：

虽然Sqoop支持增量同步但还属于粗粒度的离线同步，无法满足实时性的需求
每次同步Sqoop以sql的方式向Mysql发出数据请求也在一定程度上对Mysql带来一定的压力
同时Hive对数据更新的支持也相对较弱

为了更有效地连接前端业务数据系统（MySQL）和后端统计分析系统（查询分析引擎），我们需要一套实时同步MySQL数据的解决方案。
小米内部实践如何能够做到数据的实时同步呢？我们想到了MySQL主从复制时使用的binlog日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗时间
下面来看一下MySQL主从复制的原理，主要有以下几个步骤：

master（主库）在每次准备提交事务完成数据更新前，将改变记录到二进制日志(binary log)中
slave（从库）发起连接，连接到master，请求获取指定位置的binlog文件
master创建dump线程，推送binlog的slave
slave启动一个I/O线程来读取主库上binary log中的事件，并记录到slave自己的中继日志(relay log)中
slave还会起动一个SQL线程，该线程从relay log中读取事件并在备库执行，完成数据同步
slave记录自己的binlog

文章插图

binlog记录了Mysql数据的实时变化，是数据同步的基础，服务需要做的就是遵守Mysql的协议，将自己伪装成Mysql的slave来监听业务从库，完成数据实时同步。
结合小米内部系统特点，构建了Mysql数据同步服务–-LCSBinlog，作为一种独立的数据接入方式整合在Talos Platform中，Talos Platform作为大数据集成的基础解决方案，以自研消息队列Talos为数据总线，连接各种系统为主要目标，提供丰富的数据Source输入和数据Sink输出，并且Talos天然支持流式计算，因此业务可以充分利用Talos Platform互联互通的特性，并结合自身的业务需求实现更加高阶的业务场景。

文章插图

上图是Talos Platform中的整体流程架构，其中标红部分是目前LCSBinlog在小米内部使用最广泛的一条链路：Mysql ---> Talos ---> Kudu ---> BI，数据同步到kudu后借助Sparksql查询引擎为上层BI系统提供即席查询服务，Kudu和Sparksql的整合细节可以参见往期内容：告别”纷纷扰扰”—小米OLAP服务架构演进
LCSBinlog服务的主体架构服务一共有两种角色
Master ：主要负责作业的调度，
Worker：主要完成具体的数据同步任务
在Worker上运行两种作业：