canal

本文详解canal的整体架构。 一、整体架构 说明： server代表一个canal运行实例，对应于一个jvm instance对应于一个数据队列 （1个server对应1..n个instance) instance模块： eventParser (数据源接入，模拟slave协议和master进行交互，协议解析) eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作) eventStore (数据存储) metaManager (增量订阅&消费信息管理器) 二、各模块架构 2.1 Parser 整个parser过程大致可分为几步： Connection获取上一次解析成功的位置（如果第一次启动，则获取初始制定的位置或者是当前数据库的binlog位点） Connection建立连接，发生BINLOG_DUMP命令 Mysql开始推送Binary Log 接收到的Binary Log通过Binlog parser进行协议解析，补充一些特定信息 传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功 存储成功后，定时记录Binary Log位置 2.2 Sink 说明： 数据过滤：支持通配符的过滤模式，表名，字段内容等 数据路由/分发：解决1:n (1个parser对应多个store的模式) 数据归并：解决n:1

参考文档 https://github.com/alibaba/canal/wiki/QuickStart mysql开启bin-log日志 log_bin = /var/lib/mysql/bin-log skip-name-resolve binlog-format=ROW 创建canal对象 CREATE USER canal IDENTIFIED BY 'canal'; GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%'; flush privileges; 下载canal wget https://github.com/alibaba/canal/releases/download/canal-1.1.4/canal.deployer-1.1.4.tar.gz 编写canal.properties cat /usr/local/canal/conf/canal.properties ----------------------------------------------------- ################################################# ######### common argument ############# ######

吐槽 Canal是一种新技术,对于新技术,大家都是懵逼的,最简单的是找准一个切入点,切进去,选择一个什么切入点呢? 一般选择官网,去官网看简易的Demo(吐槽:官网的demo很简易,只能满足你的一些低级需求,高级的就得看一些高手的研究文章) 使用篇 linux安装canal server #创建canal目录 mkdir /tmp/canal #下载canal客户端 get https://github.com/alibaba/canal/releases/download/canal-1.1.0/canal.deployer-1.1.0.tar.gz #解压客户端 tar -zxvf canal.deployer-1.1.0.tar.gz canal.properties修改 ################################################# ######### common argument ############# ################################################# canal.id= 1 canal.ip=xxx.xxx.xxx.xxx canal.port=11111 canal.metrics.pull.port=11112 canal.zkServers=ip1:2181,ip2

1、概述 　　　　1.1、 canal用途 ： 　　　　　　　　　　基于 Mysql数据库 增量日志解析 ，提供 增量数据 订阅 、 消费 ； 　　　　1.2、canal 支持源端 MySQL 版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x； 2、工作原理 　　　　 3、实战 　　　　3.1、 Mysql 开启Binlog写入功能 ， 配置 binlog-format 为 ROW 模式 ， my.cnf 中配置 如下： 　　　　　　　　 [mysqld] 　　　　　　　　 log-bin=mysql-bin # 开启 binlog 　　　　　　　　　binlog-format=ROW # 选择 ROW 模式 　　　　　　　　　 server_id=1 # 配置 MySQL replaction 需要定义，不要和 canal 的 slaveId 重复 　　　　　　　　　　【注意】：注意：针对 阿里云 RDS for MySQL , 默认打开了 binlog , 并且账号默认具有 binlog dump 权限 , 不需要任何权限或者 binlog 设置,可以直接跳过这一步； 　　　　3.2、 Mysql 授权 canal 链接 MySQL 账号 具有 作为 MySQL slave 的权限, 如果已有账户可直接 grant： 　　　　　　　　

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 准备： mysql：v5.7 canal-server：v1.4.1 elasticsearch：v7.5.1 创建网络： docker network create net 创建 volume ： docker volume create elasticsearch docker volume create mysql 创建 container ： #mysql docker run -d --name mysql -p 3306:3306 --privileged=true -v mysql:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123 --net net mysql:5.7 --log-bin=mysql-bin --binlog-format=ROW --server_id=101 #canal server docker run -d --name canal-server --net net -p 11111:11111 -e canal.instance.master.address=mysql:3306 \ -e canal.instance.dbUsername=root \ -e canal.instance.dbPassword=123 \ -e

1. 作用： 同步mysql；做拉链表；更新redis 某些情况无法从日志中获取信息，而又无法利用sqoop等ETL工具对数据实时的监控 2. canal的工作原理： canal的工作原理很简单，就是把自己伪装成slave，假装从master复制数据。 3. mysql的binlog 　　MySQL的二进制日志可以说是MySQL最重要的日志了，它记录了所有的 DDL 和 DML (除了数据查询语句)语句，以 事件形式记录 ，还包含 语句所执行的消耗的时间 ， MySQL的二进制日志是事务安全型的。 一般来说开启二进制日志大概会有1%的性能损耗 。二进制有两个最重要的使用场景： 　　其一： MySQL Replication 在 Master 端开启 binlog ， Master把它的二进制日志传递给slaves来达到master-slave数据一致的目的 。 　　其二：自然就是数据恢复了，通过使用 mysqlbinlog 工具来使恢复数据。 二进制日志包括两类文件： 二进制日志索引文件 （文件名后缀为 .index ）用于记录所有的二进制文件， 二进制日志文件（文件名后缀为.00000*） 记录数据库所有的DDL和DML(除了数据查询语句)语句事件。 4. 分类 mysql binlog的格式，是有三种，分别是 STATEMENT , MIXED , ROW

缓存操作 读缓存 读缓存可以分为两种情况命中（cache hit）和未命中（cache miss）： 缓存命中 首先从缓存中获取数据 将缓存中的数据返回 缓存未命中 首先从缓存中获取数据 此时缓存未命中，从数据库获取数据 将数据写入缓存 返回数据 读缓存的的处理由 缓存中有没有数据？ 决定，如果缓存中有数据那就是 缓存命中 ，如果没有那就是 缓存未命中 ： 写缓存 写缓存可以分为 更新缓存 和 删除缓存 。 更新缓存 更新缓存时需要分两种情况： 更新简单数据类型（如string） 更新复杂数据类型 （如hash） 对于 简单数据类型 可以直接更新缓存，如果是复杂数据类型会增加额外的更新开销： 从缓存中获取数据 将数据序反列化成对象 更新对象数据 将更新后的数据序列化存入缓存 对复杂数据缓存的更新最少需要4步，而且每次写数据时都需要更新缓存，这样对读缓存较少的场景，可能更新数据7-8次读缓存才发生一次想想就划不来，另外每次更新缓存时都要对缓存数据进行计算，很明显写数据时计算缓存数据然后再更新缓存是没必要的， 可以将缓存的更新，推迟到读缓存（缓存未命中）时 。 删除缓存 删除缓存也称为 淘汰缓存 ，删除缓存的操作非常简单的，直接将缓存从缓存库中的删除就可以了。 缓存操作顺序 缓存一般都是配合数据库一起使用，从数据库中获取数据然后再更新缓存。为什么要讨论缓存操作的顺序呢

日常踩坑，现在公司使用的ES还是5.3.3版本，但是canal目前只支持6.X以上版本，canal是这么建议的： canal adapter 的 Elastic Search 版本支持6.x.x以上, 如需其它版本的es可替换依赖重新编译client-adapter.elasticsearch模块 一般人理解似乎只需要改动依赖版本然后打包就O了，但是启动会报错，后面定位是transportAddress的问题，改动如下： 先将elasticsearch下的pom文件中依赖的elasticsearch相关组件的版本号降至5.X <dependency> <groupId>org.elasticsearch</groupId> <artifactId>elasticsearch</artifactId> <version>5.3.3</version> </dependency> <dependency> <groupId>org.elasticsearch.client</groupId> <artifactId>transport</artifactId> <version>5.3.3</version> </dependency> com.alibaba.otter.canal.client.adapter.es.ESAdapter类中 transportClient

Canal介绍 早期，阿里巴巴 B2B 公司因为存在杭州和美国双机房部署，存在跨机房同步的业务需求。不过早期的数据库同步业务，主要是基于 trigger 的方式获取增量变更，不过从 2010 年开始，阿里系公司开始逐步的尝试基于数据库的日志解析，获取增量变更进行同步，由此衍生出了增量订阅 & 消费的业务，从此开启了一段新纪元。 ps. 目前内部版本已经支持 mysql 和 oracle 部分版本的日志解析，当前的 canal 开源版本支持 5.7 及以下的版本 (阿里内部 mysql 5.7.13, 5.6.10, mysql 5.5.18 和 5.1.40/48) 基于日志增量订阅 & 消费支持的业务： 数据库镜像 数据库实时备份 多级索引 (卖家和买家各自分库索引) search build 业务 cache 刷新 价格变化等重要业务消息 前期准备 mysql的binlog模式需要是ROW，查看binlog格式命令：show variables like 'binlog_format'; 订阅binlog账号需要开启下面3个权限：SELECT, REPLICATION SLAVE, REPLICATION CLIENT，查看权限命令：show grants for 'canal' Canal部署 项目地址： https://github.com/alibaba/canal

https://github.com/alibaba/canal/issues/866 ################################################# ## mysql serverId , v1.0.26+ will autoGen # canal.instance.mysql.slaveId=0 # enable gtid use true/false canal.instance.gtidon=false canal.instance.parser.parallel=false # position info canal.instance.master.address=mysql:3306 canal.instance.master.journal.name=mysql-bin.000004 canal.instance.master.position=2606 canal.instance.master.timestamp= canal.instance.master.gtid= # rds oss binlog canal.instance.rds.accesskey= canal.instance.rds.secretkey= canal.instance.rds.instanceId= # table meta tsdb info