之前因为懒，没有针对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记录形式：
- 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
你可以通过以下命令查看自己的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- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
上文中说过binlog中是以event的形式记录日志的，所以你可以通过事件命令查看具体的日志内容及位置
SHOW BINLOG EVENTS
[IN 'log_name']
[FROM pos]
[LIMIT [offset,] row_count]- 1
- 2
- 3
- 4
比如：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 - 1
具体的选项参考：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- 1
返回数据如下，黑色背景部分为一个事件的完整日志，红框标记则为执行的SQL
Canal
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