数据同步工具otter(一)谈谈binlog和canal

廉价感情. 提交于 2019-12-03 12:05:58

数据同步工具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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!