1、MySQL主从复制原理
2、Canal 的工作原理
- canal模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议
- mysql master收到dump请求，开始推送binary log为slave
- canal解析binary log对象（原始为byte流）
3、MySQL的binary log
MySQL 的二进制日志可以说是 MySQL 最重要的日志了，它记录了所有的 DDL 和DML (除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
一般来说开启 binlog 日志大概会有 1% 的性能损耗。 binlog日志有两个最重要的使用场景:
- MySQL Replication 在 Master 端开启 binlog，Mster 把它的二进制日志传递给 slaves 来达到 master-slave 数据一致的目的。
- 自然就是数据恢复了，通过使用 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的方式进行处理
- 包含UUID（）时
- 包含 auto_increment字段的表被更新时
- 执行 insert delayed语句时
- 用UDF时
优点：节省空间，同时兼顾了一定的一致性。
缺点：还有些极个别情况依旧会造成不一致，另外statement和mixed对于需要对binlog 的监控的情况都不方便。
由于 canal 是监控的数据的变化, 所以 binlog 的格式需要设置成 row 格式。
