浅谈阿里开源中间件Canal

1、MySQL主从复制原理

2、Canal 的工作原理

  1. canal模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议

  2. mysql master收到dump请求，开始推送binary log为slave

  3. canal解析binary log对象（原始为byte流）

3、MySQL的binary log

MySQL 的二进制日志可以说是 MySQL 最重要的日志了，它记录了所有的 DDL 和DML (除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。

一般来说开启 binlog 日志大概会有 1% 的性能损耗。 binlog日志有两个最重要的使用场景:

  1. MySQL Replication 在 Master 端开启 binlog，Mster 把它的二进制日志传递给 slaves 来达到 master-slave 数据一致的目的。

  2. 自然就是数据恢复了，通过使用 mysql binlog 工具来使恢复数据

4、binary log 格式

binlog有3中格式：statement，row，mixed

4.1 statement

语句级别

binlog会记录每次执行的写操作的语句，注意记录的是语句，salve会自动重新执行写操作语句，从而达到与master一致

优点： 节省空间

缺点： 有可能造成数据不一致（例如：随机数) 再比如update tt set create_date=now()，如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。

4.2 row

行级

binlog会记录每次操作后每行记录的变化

优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。

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

4.3 mixed

statement的升级版，一定程度上解决了因为一些情况而造成的statement模式不一致问题

在某些情况下会按照 ROW的方式进行处理

  1. 包含UUID（）时

  2. 包含 auto_increment字段的表被更新时

  3. 执行 insert delayed语句时

  4. 用UDF时

优点：节省空间，同时兼顾了一定的一致性。

缺点：还有些极个别情况依旧会造成不一致，另外statement和mixed对于需要对binlog 的监控的情况都不方便。

由于 canal 是监控的数据的变化, 所以 binlog 的格式需要设置成 row 格式。

以上是 浅谈阿里开源中间件Canal 的全部内容， 来源链接： utcz.com/a/29854.html

回到顶部