關於Mysql的主從(master, slave)mysql
能夠給mysql配置主從,master會將binlog發送給slave,而後slave解析binlog,同步數據。git
以此來保證兩個數據庫的數據相同。github
Canal 正是經過這種方式,假裝爲一個slave server,向mysql master發送dump協議,而後master向slave推送binlog,而後解析這個binlog,再將這個消息解析,並推送給客戶端。客戶端就能夠根據本身的業務邏輯去處理增量數據了(這個增量也能夠是刪除和修改)。spring
Canal正在運行的話,會在zk的這個節點下面有相關運行信息。客戶端正是經過這裏的信息來連接canal的。sql
[zk: localhost:2181(CONNECTED) 21] get /otter/canal/destinations/database/running數據庫
{"active":true,"address":"172.17.0.1:11111","cid":1}ide
當配置成zk模式後,會將位點信息保存至zk中。post
[zk: localhost:2181(CONNECTED) 23] get /otter/canal/destinations/database/1001/cursorui
{"@type":"com.alibaba.otter.canal.protocol.position.LogPosition","identity":{"slaveId":-1,"sourceAddress":{"address":"localhost","port":3306}},"postion":{"gtid":"","includspa
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
而官網中也沒有這個文件的含義,不過應該是這種配置會將位置點記錄到本地文件中。(實際調試發現確實是這樣的)