canal 使用

使用场景

场景1: 更新缓存

场景2:抓取业务数据表的新增和变化数据，用于制作拉链表
场景3:抓取业务数据表的新增和变化数据，用于实时统计

工作原理

把自己伪装成slave 假装从master 复制数据

复制过程分为三步
1、master 主库 DDL DML 除了查询语句写进二进制文件(binary log)中。
2、slave 从库向master 发送dump协议，将master 的 binary log events 拷贝到自己的中继日志(relay log) 中。
3、slave 读取并重做 中继日志中的事件，将改变的数据同步到自己的数据库。

mysql的binlog

MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。
一般来说开启二进制日志大概会有1%的性能损耗 。二进制有两个最重要的使用场景:
其一：MySQL Replication在Master端开启binlog，Mster把它的二进制日志传递给slaves来达到master-slave数据一致的目的。
其二：自然就是数据恢复了，通过使用mysqlbinlog工具来使恢复数据。

二进制日志包括两类文件：二进制日志索引文件（文件名后缀为.index）用于记录所有的二进制文件，二进制日志文件（文件名后缀为.00000*）记录数据库所有的DDL和DML(除了数据查询语句)语句事件

binlog的开启

编辑my.cnf文件 在[mysqld]区块添加

log-bin=mysql-bin

binlog的分类设置
mysql binlog的格式，那就是有三种，分别是STATEMENT,MIXED,ROW。
在配置文件中可以选择配置

binlog_format=row

区别：
1） statement
语句级，binlog会记录每次一执行写操作的语句。
相对row模式节省空间，但是可能产生不一致性，比如
update tt set create_date=now()
如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。
优点： 节省空间
缺点： 有可能造成数据不一致。
2） row
行级， binlog会记录每次操作后每行记录的变化。
优点：保持数据的绝对一致性。因为不管sql是什么，引用了什么函数，他只记录执行后的效果。
缺点：占用较大空间。

3） mixed
statement的升级版，一定程度上解决了，因为一些情况而造成的statement模式不一致问题
在某些情况下譬如：
当函数中包含 UUID() 时；
包含 AUTO_INCREMENT 字段的表被更新时；
执行 INSERT DELAYED 语句时；
用 UDF 时；
会按照 ROW的方式进行处理
优点：节省空间，同时兼顾了一定的一致性。
缺点：还有些极个别情况依旧会造成不一致，另外statement和mixed对于需要对binlog的监控的情况都不方便。

mysql准备

在mysql 中执行
创建用户赋予权限

GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%' IDENTIFIED BY 'canal' ;
flush privileges;

修改my.cnf 文件

server-id= 1
log-bin=mysq