canal工作原理

ゞ浴缸里的玫瑰 2022-11-08 14:24 101阅读 0赞

# canal工作原理 #

## mysql的主从复制原理 ##

1.  MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
2.  MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
3.  MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70]

## canal工作原理 ##

1.  canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
2.  MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
3.  canal 解析 binary log 对象(原始为 byte 流)  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]

## mysql的binlog ##

### 什么binlog ###

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

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

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

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

### 开启binlog ###

默认情况下, mysql是没有开启binlog的, 需要手动开启.  
开启步骤:

1.  找到mysql的配置文件:`my.cnf.` 大部分的mysql版本默认在:`/etc/my.cnf`.如果没有找到, 则可以通过下面的命令查找:

sudo find / -name my.cnf

1.  修改my.cnf. 在my.cnf文件中增加如下内容:

server-id= 1
    log-bin=mysql-bin
    binlog_format=row
    binlog-do-db=gmall

#### 配置说明 ####

server-id:  
mysql主从复制的时候, 主从之间每个实例必须有独一无二的id

log-bin:  
这个表示binlog日志的前缀是mysql-bin ，以后生成的日志文件就是 mysql-bin.123456 的文件后面的数字按顺序生成。 每次mysql重启或者到达单个文件大小的阈值时，新生一个文件，按顺序编号。

Binlog\_format:  
mysql binlog的格式，有三种值，分别是statement, row, mixed

**三者区别:**  
statement:

> 语句级，binlog会记录每次一执行写操作的语句。  
> 相对row模式节省空间，但是可能产生不一致性，比如  
> update tt set create\_date=now()  
> 如果用binlog日志进行恢复，由于执行时间不同可能产生的数据就不同。  
> 优点： 节省空间  
> 缺点： 有可能造成数据不一致。

row:

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

mixed:

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

**由于canal不是数据库, 是不能执行sql语句的, 所以, 只能设置为row格式**

binlog-do-db:  
设置把哪个database的变化写入到binlog, 如果不配置, 则所有database的变化都会写入到binlog.  
如果要设置多个数据库需要, 需要写多次这个参数的配置

binlog-do-db = a
    binlog-do-db = b

检测配置是否成功  
A: 重启mysql服务器.

sudo systemctl restart mysqld

B: 启动msyql客户端, 执行sql语句:

show variables like'%log_bin%'

![在这里插入图片描述][20210313235354817.png]

C: 也可以去对应的目录下查看是否生成log\_bin文件  
![在这里插入图片描述][20210313235401551.png]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70]: /images/20221023/59cd46c04e4a4503956e9911a8a5041c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80Mjc5NjQwMw_size_16_color_FFFFFF_t_70 1]: /images/20221023/04245f97c8e543f2b8f77b6069d722ac.png
[20210313235354817.png]: /images/20221023/79cedaf451b04fedb676733a2b704292.png
[20210313235401551.png]: /images/20221023/db76b198356f4576a4d408c757320d8e.png