Canal的原理

为什么需要 Canal

• 从 Mysql 到 Kafka 的过程中, 如果每次都是全表扫描进行数据的转移, 则非常耗时, - - [ ] 并且也会对 Mysql 造成性能的影响.
• 最好的办法是使用专门的工具能够实时的监控 Mysql 数据的变化.
• Canal 就是一个我们想要的工具.
• Canal 的作用就是实时同步 Mysql

Canal 工作原理

Mysql 的主从复制

Canal 的工作原理

Canal 的工作原理很简单， 就是把自己伪装成 slave，假装从 master 复制数据 。

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

Mysql 的 Binary log

• MySQL 的二进制日志可以说是 MySQL 最重要的日志了，它记录了所有的 DDL 和DML (除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
• 一般来说开启 binlog 日志大概会有 1% 的性能损耗。 binlog日志有两个最重要的使用场景:

1. MySQL Replication 在 Master 端开启 binlog，Mster 把它的二进制日志传递给 slaves 来达到 master-slave 数据一致的目的。
2. 自然就是数据恢复了，通过使用 mysql binlog 工具来使恢复数据。

binlog 格式

binlog 有 3 种格式: STATEMENT, ROW, MIXED

1. statement
   语句级别, binlog 会记录每次执行的写操作的语句, 注意记录的是语句, slave 会自己重新执行写操作的语句, 从而达到与 master 的一致.
   但是有可能会出现主从不一致的情况: 比如存储当前时间戳, 存储一个随机值等.
   • 优点： 节省空间

• 缺点： 有可能造成数据不一致。

2. row
   行级， binlog 会记录每次操作后每行记录的变化。
   • 优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。

• 缺点：占用较大空间。 如果一条语句执行之后导致很多行发生了变化, 则会产生很多条记录

3. mixed
   statement 的升级版，一定程度上解决了因为一些情况而造成的 statement模式不一致问题
   在某些情况下会按照 ROW的方式进行处理

1. 当函数中包含 UUID() 时； 
2. 包含 AUTO_INCREMENT 字段的表被更新时；
3. 执行 INSERT DELAYED 语句时；
4. 用 UDF 时；         - 优点：节省空间，同时兼顾了一定的一致性。

• 缺点：还有些极个别情况依旧会造成不一致，另外statement和mixed对于需要对binlog 的监控的情况都不方便。
由于 canal 是监控的数据的变化, 所以 binlog 的格式需要设置成 row 格式