Canal教程（2）Canal常见问题与解决方法
在部署和使用Canal中常见问题解决办法：
1、Canal日志提示command : 'show binlog events limit 1' has an error!
方法：首先看提示会想到是MySQL的binlog问题，可是经过检查binlog是开启的，通过flush logs也能正常刷新日志，同时binlog的index文件里也都记录有新的日志文件信息。后来发现index文件第一行是空行，而空行被认为是文件结束，所以当Canal去获取binlog信息时就直接结束了导致读不到正确日志。只需要删掉这个空行然后flush logs即可恢复
2、instance的日志输出"column size is not match for table:pluto_is_web.t_abnormal,6 vs 7"报错
方法：这种问题是因为表结构被缓存在了Canal的本地时序数据库中，而后来数据结构发生了变化。6 vs 7是指当前表结构有6列数据，但是Canal中出现了7列，导致数据不一致无法解析。只需要清空报错的那个instance目录中的h2.mv.db文件即可
3、instance日志中输出could not find first log file name in binary log index file
网上搜相关错误都是说MySQL binlog的问题，其实跟MySQL没有关系。这个是因为zk集群中缓存了binlog信息导致拉取的数据不对，包括定义了binlog position但是启动服务后不对也是同样的原因。解决办法：如果是单机部署的话删除canal/conf/$instance目录中的meta.dat文件即可，如果是集群模式需要进入zk删除/otter/canal/destinations/xxxxx/1001/cursor，然后重启canal
./zkCli.sh -server 172.20.7.153:2181 [zk: 172.20.7.153:2181(CONNECTED) 1] rmr /otter/canal/destinations/linuxe/1001/cursor
4、消息体过大
这里涉及到canal和Kafka两个配置,当消息体大小超出了canal端配置maxRequestSize的配置后,错误日志里会明确消息体大小，类似"The message is 17853226 bytes when serialized which is larger than the maximum request size you have configured with the max.request.size configuration."。如果消息体大小超出了canal端的配置且超出了Kafka端的限制,就只会输出"The request included a message larger than the max message size the server will accept"
#canal相关配置
canal.mq.maxRequestSize = 104857600 #调大可接收消息体大小
canal.mq.compressionType = lz4 #开启消息体压缩功能
5、时间戳设置不生效
如果出现配置了binlog位点或timestamp但是实际同步位点不对的情况，需要登录zookeeper找到相应的节点进行删除才行
zkCli.sh -server 10.5.3.7:12181 rmr /otter/canal/destinations/channel_cpp
评论