数据同步工具otter（一）谈谈binlog和canal

之前因为懒，没有针对otter做更多的解释和说明，在使用过程中，也发现了一些问题，此次补上一个完整的文档，方便大家使用。

Otter是基于cannal开源的，canal又是基于mysql binlog的产品。我们就从binlog说起

binlog

mysql的binlog日志是被设计用来作主从备份或者数据恢复用的。binlog是The Binary Log的简称，意思就是二进制的日志文件（可以点击https://dev.mysql.com/doc/refman/5.6/en/binary-log.html了解）。binlog中以二进制的形式记录了数据库的”events（事件）”即数据库结构及表数据发生的变化。以下这张图就反应了主从库之间使用binlog进行同步的过程：

mysql提供了三种不同的binlog记录形式：

1. STATEMENT 语句模式（默认）：日志中记录了所有的执行的sql语句，从库在执行的时候，重新执行相应sql即可。但是因为不记录语句执行的上下文，在从库执行某些语句（比如存储过程）的时候，有些语句不一定能成功执行导致丢失数据
2. ROW 行模式：日志中记录每一行每个字段的变化，能清楚记录每行数据的变化历史，主从丢失数据的情况大大降低，但是缺点是会产生大量的binlog占用存储空间
3. MIX 混合模式：在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。目前这种模式其实就是由mysql来选择到底用哪种模式记录，可以点此了解https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html

你可以通过以下命令查看自己的mysql的binlog情况：

//查看自己的mysql是否打开了binlog选项
show variables like 'log_bin'
//查看binlog的格式
show variables like 'binlog_format'

//获取binlog列表
show binary logs
//或者
show master logs

//查看正在写入的binlog
show master status

上文中说过binlog中是以event的形式记录日志的，所以你可以通过事件命令查看具体的日志内容及位置

SHOW BINLOG EVENTS
   [IN 'log_name']
   [FROM pos]
   [LIMIT [offset,] row_count]

比如：SHOW BINLOG EVENTS LIMIT 1

• Log_name:日志文件名
• Pos:事件起始位置
• Event_type：事件类型
• End_log_pos结束位置

mysqlbinlog工具

如果binlog的格式是STATEMENT，以上show binlog event的方式是可以看到sql语句的，但是如果row模式的话，没法看到，只能通过mysqlbinlog工具进行查看，mysqlbinlog也是mysql dba常用的备份恢复数据的工具。

该工具需要登录到数据库主机使用

mysqlbinlog [options] log_file 

具体的选项参考：https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog.html

如果你没有数据库主机的登录权限，可以选择使用远程导出的方式将远端的binlog导出。

# mysqlbinlog -u用户名 -p密码 -h主机地址 -P端口号 --read-from-remote-server mysql-bin.000001 --base64-output=decode-rows -v > 1.txt

返回数据如下，黑色背景部分为一个事件的完整日志，红框标记则为执行的SQL

Canal

canal(https://github.com/alibaba/canal)是阿里出品基于binlog的一款订阅消费组件，简单来说也就是它可以订阅mysql的binlog，并进行读取消费，以达到数据同步等目的。相较于传统的触发器同步数据模式，基于binlog的数据同步方式无疑灵活性、功能性更强。

原理如下：

1. canal模拟mysql slave的交互协议，伪装自己为mysql slave，向mysql master发送dump协议
2. mysql master收到dump请求，开始推送binary log给slave(也就是canal)
3. canal解析binary log对象(原始为byte流)

canal服务端：

这张图表示了canal服务端的模块划分

• server代表一个canal运行实例，对应于一个jvm
• instance对应于一个数据队列（也就是一个数据库的binlog订阅者） （1个server对应1..n个instance)

instance下的子模块：

• eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
• eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
• eventStore (数据存储)
• metaManager (增量订阅&消费信息管理器)

canal客户端：

canal客户端可以向服务器端进行消息订阅消费，服务器端的解析后的数据存在eventStore中，而客户端的工作就是从eventStore中订阅消费。

好了，我们已经对canal大概了解了，下一篇文档我们进入我们的正题otter