之前因为懒,没有针对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
<https://dev.mysql.com/doc/refman/5.6/en/binary-log.html>
了解)。binlog中以二进制的形式记录了数据库的”events(事件)”即数据库结构及表数据发生的变化。以下这张图就反应了主从库之间使用binlog进行同步的过程:



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

* STATEMENT
语句模式(默认):日志中记录了所有的执行的sql语句,从库在执行的时候,重新执行相应sql即可。但是因为不记录语句执行的上下文,在从库执行某些语句(比如存储过程)的时候,有些语句不一定能成功执行导致丢失数据
* ROW 行模式:日志中记录每一行每个字段的变化,能清楚记录每行数据的变化历史,主从丢失数据的情况大大降低,但是缺点是会产生大量的binlog占用存储空间
* MIX 混合模式:在 Mixed 模式下,MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式,也就是在 statement 和
row 之间选择一种。比如遇到表结构变更的时候就会以 statement 模式来记录,如果 SQL 语句确实就是 update 或者 delete
等修改数据的语句,那么还是会记录所有行的变更。目前这种模式其实就是由mysql来选择到底用哪种模式记录,可以点此了解
https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html
<https://dev.mysql.com/doc/refman/5.6/en/binary-log-mixed.html>
你可以通过以下命令查看自己的mysql的binlog情况:
//查看自己的mysql是否打开了binlog选项 show variables like 'log_bin' //查看binlog的格式 show
variableslike 'binlog_format' //获取binlog列表 show binary logs //或者 show master
logs //查看正在写入的binlogshow 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
<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 <https://github.com/alibaba/canal>
)是阿里出品基于binlog的一款订阅消费组件,简单来说也就是它可以订阅mysql的binlog,并进行读取消费,以达到数据同步等目的。相较于传统的触发器同步数据模式,基于binlog的数据同步方式无疑灵活性、功能性更强。



原理如下:

* canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql master发送dump协议
* mysql master收到dump请求,开始推送binary log给slave(也就是canal)
* 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

友情链接
KaDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信