标签：Canal binlog 入门 log MySQL 日志 canal

一. Canal 入门

1.1 Canal 是什么

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费

早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括

数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理

当前的 canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x

1.2 MySQL的主从架构

MySQL的主从架构

MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

1.3 Canal 架构

canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送dump 协议
MySQL master 收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)

1.4 MySQL 的binlog

1.4.1 binlog 是什么

MySQL中一般有以下几种日志：

日志类型	写入日志的信息
错误日志	记录在启动，运行或停止mysqld时遇到的问题
通用查询日志	记录建立的客户端连接和执行的语句
二进制日志	记录更改数据的语句
中继日志	从复制主服务器接收的数据更改
慢查询日志	记录所有执行时间超过 `long_query_time` 秒的所有查询或不使用索引的查询
DDL日志（元数据日志）	元数据操作由DDL语句执行

MySQL 的二进制日志 binlog 可以说是 MySQL 最重要的日志，它记录了所有的 DDL 和 DML 语句（除了数据查询语句select、show等），以事件形式记录，还包含语句所执行的消耗的时间，MySQL的二进制日志是事务安全型的。binlog 的主要目的是复制和恢复。

一般来说开启binlog日志大概会有1%的性能损耗。

启用binlog，通过配置 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf 配置文件的 log-bin 选项：

在配置文件中加入 log-bin 配置，表示启用binlog，如果没有给定值，写成 log-bin=，则默认名称为主机名。（注：名称若带有小数点，则只取第一个小数点前的部分作为名称）

1.4.2 binlog 的配置

在MySQL的配置文件(Linux: /etc/my.cnf , Windows: \my.ini)下,修改配置

在[mysqld]区块

设置/添加

log-bin=mysql-bin-zhang

server-id= 1

binlog_format=row

binlog-do-db=gmall

常用的Binlog操作命令

可以通过 SET SQL_LOG_BIN=1 命令来启用 binlog，通过 SET SQL_LOG_BIN=0 命令停用 binlog。启用 binlog 之后须重启MySQL才能生效。

# 是否启用binlog日志
show variables like 'log_bin';

# 查看详细的日志配置信息
show global variables like '%log%';

# mysql数据存储目录
show variables like '%dir%';

# 查看binlog的目录
show global variables like "%log_bin%";

# 查看当前服务器使用的biglog文件及大小
show binary logs;

# 查看主服务器使用的biglog文件及大小

# 查看最新一个binlog日志文件名称和Position
show master status;


# 事件查询命令
# IN 'log_name' ：指定要查询的binlog文件名(不指定就是第一个binlog文件)
# FROM pos ：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)
# LIMIT [offset,] ：偏移量(不指定就是0)
# row_count ：查询总条数(不指定就是所有行)
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

# 查看 binlog 内容
show binlog events;

# 查看具体一个binlog文件的内容 （in 后面为binlog的文件名）
show binlog events in 'master.000003';

# 设置binlog文件保存事件，过期删除，单位天
set global expire_log_days=3; 

# 删除当前的binlog文件
reset master; 

# 删除slave的中继日志
reset slave;

# 删除指定日期前的日志索引中binlog日志文件
purge master logs before '2020-10-13 14:00:00';

# 删除指定日志文件
purge master logs to 'master.000003';

1.4.3 写 Binlog 的时机]

对支持事务的引擎如InnoDB而言，必须要提交了事务才会记录binlog。binlog 什么时候刷新到磁盘跟参数 sync_binlog 相关。

如果设置为0，则表示MySQL不控制binlog的刷新，由文件系统去控制它缓存的刷新；
如果设置为不为0的值，则表示每 sync_binlog 次事务，MySQL调用文件系统的刷新操作刷新binlog到磁盘中。
设为1是最安全的，在系统故障时最多丢失一个事务的更新，但是会对性能有所影响。

如果 sync_binlog=0 或 sync_binlog大于1，当发生电源故障或操作系统崩溃时，可能有一部分已提交但其binlog未被同步到磁盘的事务会被丢失，恢复程序将无法恢复这部分事务。

在MySQL 5.7.7之前，默认值 sync_binlog 是0，MySQL 5.7.7和更高版本使用默认值1，这是最安全的选择。一般情况下会设置为100或者0，牺牲一定的一致性来获取更好的性能。

1.4.4 Binlog 的日志格式

记录在二进制日志中的事件的格式取决于二进制记录格式。支持三种格式类型：

STATEMENT：基于SQL语句的复制（statement-based replication, SBR）
ROW：基于行的复制（row-based replication, RBR）
MIXED：混合模式复制（mixed-based replication, MBR）

在 MySQL 5.7.7 之前，默认的格式是 STATEMENT，在 MySQL 5.7.7 及更高版本中，默认值是 ROW。日志格式通过 binlog-format 指定，如 binlog-format=STATEMENT、binlog-format=ROW、binlog-format=MIXED。

Statement

每一条会修改数据的sql都会记录在binlog中

优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO, 提高了性能。

缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的一些相关信息，以保证所有语句能在slave得到和在master端执行的时候相同的结果。另外mysql的复制，像一些特定函数的功能，slave与master要保持一致会有很多相关问题。

Row

5.1.5版本的MySQL才开始支持 row level 的复制,它不记录sql语句上下文相关信息，仅保存哪条记录被修改。

优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以row的日志内容会非常清楚的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题.

缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容。

注：将二进制日志格式设置为ROW时，有些更改仍然使用基于语句的格式，包括所有DDL语句，例如CREATE TABLE， ALTER TABLE，或 DROP TABLE。

Mixed

从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。在Mixed模式下，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则采用row格式保存binlog，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。

1.5 Canal 安装

1.5.1 下载地址]

https://github.com/alibaba/canal/releases

1.5.2 配置

https://github.com/alibaba/canal/wiki/Canal-Kafka-RocketMQ-QuickStart

1. 服务端配置

canal.properties类似于Canal服务

vim conf/canal.properties
#高可用配置【这里可以不配置】
canal.zkServers = node01:2181,node02:2181,node03:2181
#服务模式【修改为Kafka】
canal.serverMode = kafka
canal.mq.servers = node01:9092,node02:9092,node03:9092
#【不需要修改，但是要知道】
canal.destinations = example

2. MySQL实例

instance.properties相当于MySQL实例

 vim conf/example/instance.properties
 canal.instance.master.address=node03:3306
 canal.instance.dbUsername=root
canal.instance.dbPassword=123456
canal.mq.topic=GMALL_DB
canal.mq.partitionsNum=6

3.docker部署canal

首先，您需要在本地或服务器上安装 Docker。
下载 Canal Server 的 Docker 镜像。您可以使用以下命令从 Docker Hub 下载 Canal 镜像：
```
docker pull canal/canal-server
```
创建 Canal Server 容器。您可以使用以下命令创建一个新的 Canal Server 容器：
```
docker run -d --name canal-server -p 11111:11111 -v /data/canal:/home/admin/canal -e canal.instance.master.address=your_database_ip:3306 canal/canal-server
```
这个命令将创建一个名为 canal-server 的新容器，将容器的 11111 端口映射到主机的 11111 端口，将 /data/canal 目录映射到容器的 /home/admin/canal 目录，并设置 canal.instance.master.address 属性为您的数据库的 IP 地址和端口。
等待 Canal Server 容器启动。您可以使用以下命令检查 Canal Server 容器是否正在运行：
```
docker ps
```
现在，您已经成功在 Docker 中部署了 Canal。注意如果想部署集群不建议使用docker，高级的配置文件可自行百度。

标签：Canal,binlog,入门,log,MySQL,日志,canal
From： https://www.cnblogs.com/runrab/p/17213251.html

Canal入门