mysql 开源~canal的深度解读1

一 简介:经过一段时间的研究,对canal有了一些见解

二 配置文件:

1 canal.properties (系统根配置文件)

    主要参数列表
   canal.properties (系统根配置文件)
   canal.destinations= example 当前server上部署的instance列表 默认为example 在canal.properties定义了canal.destinations后，需要在canal.conf.dir对应的目录下建立同名的文件

canal.auto.scan 开启instance自动扫描 如果配置为true，canal.conf.dir目录下的instance配置变化会自动触发：
          a. instance目录新增： 触发instance配置载入，lazy为true时则自动启动
          b. instance目录删除：卸载对应instance配置，如已启动则进行关闭
          c. instance.properties文件变化：reload instance配置，如已启动自动进行重载

canal.auto.scan.interval=5 扫描间隔 默认5S
  canal.instance.global.mode=spring 全局配置加载方式、
  canal.zkServers=集群 ZK集群配置
  #binlog配置
  canal.instance.binlog.format = ROW,STATEMENT,MIXED 支持的binlog格式
  canal.instance.binlog.image = FULL,MINIMAL,NOBLOB 支持的binlog
 #sql语句过滤
 canal.instance.filter.query.dcl = false 权限和存储过程相关语句 设置为false 表示不丢弃
 canal.instance.filter.query.dml = false 删增改相关语句 设置为false 表示不丢弃
 canal.instance.filter.query.ddl = false DDL相关语句 设置为false 表示不丢弃
 canal.instance.filter.table.error = false

三 关于 canal destinations
   1 server第一次启动时，会自动扫描conf目录下，将文件名做为instance name，启动对应的instance
   2 server运行过程中，会根据canal.auto.scan.interval定义的频率，进行扫描
         1. 发现目录有新增，启动新的instance
         2. 发现目录有删除，关闭老的instance
         3. 发现对应目录的instance.properties有变化，重启instance
  3 通过以上可以看出 不必再配置文件中增加实例定义,扫描会自动发现

四 关于 canal 扫描的binlog
   1 canal.instance.master.journal.name + canal.instance.master.position : 精确指定一个binlog位点，进行启动
   2 canal.instance.master.timestamp : 指定一个时间戳，canal会自动遍历mysql binlog，找到对应时间戳的binlog位点后，进行启动
   3 不指定任何信息：默认从当前数据库的位点，进行启动。(show master status)
五 关于 canal的 实例meta
   1 每个 instance 下 如果被应用读取,都有一个 meta文件,里面记录着同步的详细信息
  {"clientDatas":[{"clientIdentity":{"clientId":1001,"destination":"dbname","filter":"过滤规则"},"cursor":{"identity":{"slaveId":-1,"sourceAddress":{"address":"IP","port":3306}},"postion":{"included":false,"journalName":"mysql-    bin.000085","position":283121001,"timestamp":1512620199000}}}],"destination":"dbname"}
  包括过滤规则,instance name,同步信息(主库 IP filename,position）
  2 通过meta存在与否可以判断当前instance是否被程序读取
 六 关于 canal的消费使用情况
   1 单独的 instance 只能一个客户端进行消费
   2 如果第一个客户端停止消费,第二个客户端进行消费的时候 binlog会继承第一个客户端进行消费
   3 只要目标数据库进行事务变更,后端消费就会出现transaction显示
七 关于 canal与ZK的配合
  1 搭建两组 canal 服务和一组ZK配置
  2 canal.zkServers=IP:PORT
  3 重启两组canal生效
  4 进入zk进行查看 get /otter/canal/destinations/example/running
  {"active":true,"address":"cannalIP1","cid":1}
  5 停止接入的canal 再进入zk进行查看
 {"active":true,"address":"cannalIP2","cid":1}

八 关于canal 研发的一些问题
 1 关于单事务的过滤问题,出现大量transaction,如何进行过滤,这是一个问题