Canal
Canal原理
原理相对比较简单:
- canal模拟mysql slave的交互协议,伪装自己为mysql slave,向mysql master发送dump协议
- mysql master收到dump请求,开始推送binary log给slave(也就是canal)
- canal解析binary log对象(原始为byte流)
Canal架构
Canal集群
大致步骤:
- canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现:创建EPHEMERAL节点,谁创建成功就允许谁启动)
- 创建zookeeper节点成功后,对应的canal server就启动对应的canal instance,没有创建成功的canal instance就会处于standby状态
- 一旦zookeeper发现canal server A创建的节点消失后,立即通知其他的canal server再次进行步骤1的操作,重新选出一个canal server启动instance.
- canal client每次进行connect时,会首先向zookeeper询问当前是谁启动了canal instance,然后和其建立链接,一旦链接不可用,会重新尝试connect.
Canal数据流程
相关问题:
canal过滤数据的单位是数据库,可以过滤到表:
参数名字 |
参数说明 |
默认值 |
canal.instance.filter.regex (白名单) |
mysql 数据解析关注的表,Perl正则表达式. 多个正则之间以逗号(,)分隔,转义符需要双斜杠(\\)
1. 所有表:.* or .*\\..* 5. 多个规则组合使用:canal\\..*,mysql.test1,mysql.test2 (逗号分隔) |
.*\\..* |
canal.instance.filter.black.regex (黑名单) |
mysql 数据解析表的黑名单,表达式规则见白名单的规则 |
无 |
Canal单实例和多实例:instance对应于一个数据队列(1个server对应1..n个instance)(canal官方文档--简介)
Canal集群仅仅是为了可靠性:为了减少对mysql dump的请求,不同server上的instance要求同一时间只能有一个处于running,其他的处于standby状态。(针对同一主备)
(canal官方文档--简介)
Otter
Otter原理
原理描述:
1. 基于Canal开源产品,获取数据库增量日志数据。
2. 典型管理系统架构,manager(web管理)+node(工作节点)
a. manager运行时推送同步配置到node节点
b. node节点将同步状态反馈到manager上
3. 基于zookeeper,解决分布式状态调度的,允许多node节点之间协同工作.
Otter架构
名词解释
- Pipeline:从源端到目标端的整个过程描述,主要由一些同步映射过程组成
- Channel:同步通道,单向同步中一个Pipeline组成,在双向同步中有两个Pipeline组成
- DataMediaPair:根据业务表定义映射关系,比如源表和目标表,字段映射,字段组等
- DataMedia : 抽象的数据介质概念,可以理解为数据表/mq队列定义
- DataMediaSource : 抽象的数据介质源信息,补充描述DateMedia
- ColumnPair : 定义字段映射关系
- ColumnGroup : 定义字段映射组
- Node : 处理同步过程的工作节点,对应一个jvm
Otter分布式架构
由于单节点容易导致宕机时数据丢失,所以可以将多个Node绑定到同一Zookeeper集群,在宕机时重新选举工作节点,实现高可用。
Otter完整搭建图
Otter完整搭建需要otter数据库,zookeeper集群,Manager管理组件和Node工作组件。otter运行时数据保存在单独的otter数据库,zookeeper实现高可用,Node完成同步数据的工作。
Otter操作
安装完成后打开manager地址例如:http://172.16.0.3:8080,默认用户名密码是admin/admin
单向同步配置:
前提条件: 数据库表结构相同