安装前准备-开启MySQL binlog

对于自建 MySQL , 需要先开启 Binlog 写入功能，配置 binlog-format 为 ROW 模式，开启Mysql binlog日志步骤如下：
登录mysql查看MySQL是否开启binlog日志

[root@node1 ~]# mysql -u root -p123456
mysql> show variables like 'log_%';

Canal 安装_数据库

开启mysql binlog日志

在/etc/my.cnf文件中[mysqld]下写入以下内容

# 随机指定一个不能和其他集群中机器重名的字符串，配置 MySQL replaction 需要定
#义，不要和 canal 的 slaveId 重复
server-id=123 
#配置binlog日志目录，配置后会自动开启binlog日志，并写入该目录
log-bin=/var/lib/mysql/mysql-bin

# 选择 ROW 模式
binlog-format=ROW

MySQL binlog-format有三种模式：Row、Statement 和 Mixed 。

  1. Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。
    优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节。
    缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。
  2. Statement(默认)：每一条会修改数据的sql都会记录在binlog中。
    这种模式下，slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。
    优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。
    缺点：由于只记录语句，所以，在statement level下 已经发现了有不少情况会造成MySQL的复制出现问题，主要是修改数据的时候使用了某些定的函数或者功能的时候会出现。 例如：update 语句中含有uuid() ,now() 这种函数时，Statement模式就会有问题（update t1 set xx = now() where xx = xx）
  3. Mixed: 混合模式
    在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志格式，也就是在Statement和Row之间选择一种。如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。
  4. 3)重启mysql 服务，重新查看binlog日志情况
[root@node1 ~]# service mysqld restart
[root@node1 ~]# mysql -u root -p123456
mysql> show variables like 'log_%';

Canal 安装_log日志_02

下载Canal

Cannal下载地址如下：https://github.com/alibaba/canal/releases,这里选择Canal 1.1.4版本下载

上传解压

将下载好的Canal安装包上传到node3节点上，解压

#首先创建目录
[root@node3 opt]# mkdir canal-1.1.4
#将Canal安装包解压到创建的canal目录中
[root@node3 apps]# tar -zxvf canal.deployer-1.1.4.tar.gz -C /opt/canal-1.1.4/
[root@node3 opt]# cd canal-1.1.4/
[root@node3 canal-1.1.4]# ll
total 16
drwxr-xr-x 2 root root 4096 Jan  4 01:26 bin
drwxr-xr-x 5 root root 4096 Jan  4 01:26 conf
drwxr-xr-x 2 root root 4096 Jan  4 01:26 lib
drwxrwxrwx 2 root root 4096 Sep  2  2019 logs