浅谈阿里开源中间件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

回到顶部