-
-
MySQL slave 将 master 的 binary log 拷贝到它的中继日志(relay log)
-
2.2 mysql binlog日志
使用场景:
MySQL 的Binlog可以说 MySQL 最重要的日志,它记录了所有的 DDL 和 DML语句,以事件形式记录。
MySQL默认情况下是不开启Binlog,因为记录Binlog日志需要消耗时间,官方给出的数据是有1%的性能损耗。
具体开不开启,开发中需要根据实际情况做取舍。
-
-
-
MySQL 主从集群部署时,需要将在 Master 端开启 Binlog,方便将数据同步到Slaves中。
-
数据恢复了,通过使用 MySQL Binlog 工具来使恢复数据。
-
-
binlog分类:
MySQL Binlog 的格式有三种,分别是 STATEMENT,MIXED,ROW。在配置文件中可以选择配置 binlog_format= statement|mixed|row。
介绍 | 优点 | 缺点 | |
---|---|---|---|
STATEMENT | 语句级别,记录每一次执行写操作的语句,相对于ROW模式节省了空间,但是可能产生数据不一致如update tt set create_date=now(),由于执行时间不同产生饿得数据就不同 | 节省空间 | 可能造成数据不一致 |
ROW | 行级,记录每次操作后每行记录的变化。假如一个update的sql执行结果是1万行statement只存一条,如果是row的话会把这个1万行的结果存这。 | 持数据的绝对一致性。因为不管sql是什么,引用了什么函数,他只记录执行后的效果 | 占用较大空间 |
MIXED | 是对statement的升级,如当函数中包含 UUID() 时,包含 AUTO_INCREMENT 字段的表被更新时,执行 INSERT DELAYED 语句时,用 UDF 时,会按照 ROW的方式进行处理 | 节省空间,同时兼顾了一定的一致性 |
综合上面对比,Canal 想做监控分析,选择 row 格式比较合适。
3.Canal工作原理
-
-
MySQL master(主库) 收到 dump 请求,开始推送 binary log 给 slave (即 canal )
-
MySQL master(主库) 收到 dump 请求,开始推送 binary log 给 slave (即 canal )
4.应用场景:
1.Canal 可以帮助用户进行多种数据同步操作,如实时同步 MySQL 数据到 Elasticsearch、Redis 等数据存储介质中。
2.
Canal 可以将 MySQL 增量数据投递到 Kafka 等消息队列中,为数据分析和挖掘提供数据来源。
4.数据库备份:Canal 可以将 MySQL 主库上的数据增量日志复制到备库上,实现数据库备份。
5.数据集成:Canal 可以将多个 MySQL 数据库中的数据进行集成,为数据处理提供更加高效可靠的解决方案。
6.数据库迁移:Canal 可以协助完成 MySQL 数据库的版本升级及数据迁移任务。
5.Canal安装
5.1.下载
下载地址
下载 解压安装即可。
5.2配置
1.
canal.port = 11111
# tcp, kafka, rocketMQ, rabbitMQ, pulsarMQ
canal.serverMode = tcp
canal.destinations = example
canal.port:默认端口 11111
canal.serverMode:服务模式,tcp 表示输入客户端,xxMQ输出到各类消息中间件
canal.destinations:canal能可以收集多个MySQL数据库数据,每个MySQL数据库都有独立的配置文件控制。具体配置规则: conf/目录下,使用文件夹放置,文件夹名代表一个MySQL实例。canal.destinations用于配置需要监控数据的数据库。如果是多个,使用,隔开
2.
canal.instance.mysql.slaveId=20
# position info
canal.instance.master.address=127.0.0.1:3306
# username/password
canal.instance.dbUsername=root
canal.instance.dbPassword=admin
canal.instance.mysql.slaveId:使用canal 从阶段id
canal.instance.master.address:数据库ip端口
canal.instance.dbUsername:连接mysql账号
canal.instance.dbPassword:连接mysql密码
3.启动