處理Canal的position > file size問題

 

關於Mysql的主從(master, slave)mysql

能夠給mysql配置主從,master會將binlog發送給slave,而後slave解析binlog,同步數據。git

以此來保證兩個數據庫的數據相同。github

 

Canal 正是經過這種方式,假裝爲一個slave server,向mysql master發送dump協議,而後master向slave推送binlog,而後解析這個binlog,再將這個消息解析,並推送給客戶端。客戶端就能夠根據本身的業務邏輯去處理增量數據了(這個增量也能夠是刪除和修改)。spring

https://camo.githubusercontent.com/46c626b4cde399db43b2634a7911a04aecf273a0/687474703a2f2f646c2e69746579652e636f6d2f75706c6f61642f6174746163686d656e742f303038302f333130372f63383762363762612d333934632d333038362d393537372d3964623035626530346339352e6a7067

 

 

 

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

 

而官網中也沒有這個文件的含義,不過應該是這種配置會將位置點記錄到本地文件中。(實際調試發現確實是這樣的)

相關文章
相關標籤/搜索