2019独角兽企业重金招聘Python工程师标准>>> 
关于Mysql的主从（master, slave）
可以给mysql配置主从，master会将binlog发送给slave，然后slave解析binlog，同步数据。
以此来保证两个数据库的数据相同。
Canal 正是通过这种方式，伪装为一个slave server，向mysql master发送dump协议，然后master向slave推送binlog，然后解析这个binlog，再将这个消息解析，并推送给客户端。客户端就可以根据自己的业务逻辑去处理增量数据了（这个增量也可以是删除和修改）。
Canal正在运行的话，会在zk的这个节点下面有相关运行信息。客户端正是通过这里的信息来链接canal的。
[zk: localhost:2181(CONNECTED) 21] get /otter/canal/destinations/database/running
{"active":true,"address":"172.17.0.1:11111","cid":1}
当配置成zk模式后，会将位点信息保存至zk中。
[zk: localhost:2181(CONNECTED) 23] get /otter/canal/destinations/database/1001/cursor
{"@type":"com.alibaba.otter.canal.protocol.position.LogPosition","identity":{"slaveId":-1,"sourceAddress":{"address":"localhost","port":3306}},"postion":{"gtid":"","includ
ed":false,"journalName":"mysql-bin.000002","position":909932,"serverId":19,"timestamp":1552458351000}}
注意点：canal.instance.gtidon=false
发现报错如下：Client requested master to start replication from position > file size
发现它获取的当前位置点不对：BinlogDumpCommandPacket[binlogPosition=18156,slaveServerId=1439,binlogFileName=mysql-bin.000001,command=18]
和在数据库中 show master status 的不同，那么这个位置到底是从哪里来的。
最终根据跟代码，找到它这个位置点是通过文件读取的，而文件正是 conf/database/meta.dat ，
打开这个文件内容，就是刚才日志中输出的位置点信息！
于是将这个文件删除，重新启动canal，一切正常了。
但是我记着之前这个位置点信息是存在zk中的，怎么现在存在文件中了？
然后看了下官网文档，https://github.com/alibaba/canal/wiki/AdminGuide
根据官方提供的，需要 default-instance.xml 才可以。
然后找了下配置文件，发现果然配的不是default！
conf/canal.properties：
canal.instance.global.spring.xml = classpath:spring/file-instance.xml
而官网中也没有这个文件的含义，不过应该是这种配置会将位置点记录到本地文件中。（实际调试发现确实是这样的）