记录一次测试环境单机canal 1.1.4版本的报错处理

报错如下：

java.io.IOException: Received error packet: errno = 1236, sqlstate = HY000 errmsg = Could not find first log file name in binary log index file

环境介绍：

1、1.1.4版本

2、单机节点

3、使用zookeeper

原因：canal主机的资源一直都很紧张，而且是测试环境，因此对待这个资源问题一直不太关注，然而有一天canal的主机CPU夯死了4天，而测试数据库是阿里云的RDS。设置的binlog日志只有保留24小时。一切就是为了省资源，省钱。平时常用处理手段就是观察CPU在这1天内是否会下降，如不会下降，就手动重启canal进程。当时遇到请假未能处理，等到第4天恢复上班，canal就找不到了之前记录的那个二进制的点位了，因为数据库的binlog日志早就被清理了。就有这句话“Could not find first log file name in binary log index file”。所以原因很快就定位到，即便重启后，canal进程正常，但是同步的instance全部报以上错误。

通过测试网上各路大神的建议，各种测试，依然不能恢复正常，所谓的删除meta.dat文件，那是不存在的。（不存在的原因耐心看到最后）canal主机上find所有文件压根就没有。

解决的第一个思路：

从数据库下手，测试找到相关的，从元数据开始想办法：

select * from  canal_metadata.meta_snapshot WHERE destination in ('test_db','db_tbl');

试图删除掉以后，重启instance，依然报错。

从页面重建一个不同名的instance，能正常！重建一个已有过的instance名字，报错依旧！！！！

这个测试得出的信息，重建新的instance是肯定没问题的，此时canal服务是没问题，它的没问题只是针对新建的instance。但是目前挂了几十个instance，不可能每个都手动重建吧？因此，一定在某个地方是在记录这它的一个状态。但是这个地方既不在数据库里也不在canal部署的主机上。

因此只有一个特别大的可能性是在zookeeper里。。。测试环境，canal单节点+zookeeper的部署。(⊙﹏⊙)

zookeeper干啥滴？？？？它是一个经典分布式数据一致性解决方案。。。而测试环境是怎么架构，它是单机单节点的架构，资源紧巴巴的还浪费这么一台主机的钱.....

意味着数据肯定持久化在zookeeper这里面了：

登录方式：

cd /usr/local/zookeeper-3.4.13/bin
./zkCli.sh -server 192.168.2.174:4282
ls /otter/canal/destinations
删除掉指定的，或者全部删除：
rmr /otter/canal/destinations/test-db-course-tbl_user_badge

然后重启instance。日志就显示正常了

因为这个配置：

导致数据持久化在zookeeper里

所以非常必要的需要了解canal.properties四种模式是啥意思：

#canal.instance.global.spring.xml = classpath:spring/local-instance.xml
#canal.instance.global.spring.xml = classpath:spring/memory-instance.xml
canal.instance.global.spring.xml = classpath:spring/file-instance.xml
#canal.instance.global.spring.xml = classpath:spring/default-instance.xml

memory-instance.xml： 所有的组件(parser , sink , store)都选择了内存版模式，记录位点的都选择了memory模式，重启后又会回到初始位点进行解析

        特点：速度最快，依赖最少(不需要zookeeper)

        场景：一般应用在quickstart，或者是出现问题后，进行数据分析的场景，不应该将其应用于生产环境。

 个人建议是调试的时候使用该模式，即新增数据的时候，客户端能马上捕获到改日志，但是由于位点一直都是canal启动的时候最新的，不适用与生产环境。

file-instance.xml ：所有的组件(parser , sink , store)都选择了基于file持久化模式，注意，不支持HA机制.

        特点：支持单机持久化

        场景：生产环境，无HA需求，简单可用.

采用该模式的时候，如果关闭了canal，会在destination中生成一个meta.dat，用来记录关键信息。如果想要启动canal之后马上订阅最新的位点，需要把该文件删掉。（所以开口就跟你说删除某个目录的下的meta.dat，就恢复的话，不要盲目相信。你得看看你是开启了什么模式的）

{“clientDatas”:[{“clientIdentity”:{“clientId”:1001,“destination”:“example”,“filter”:"…"},“cursor”:{“identity”:{“slaveId”:-1,“sourceAddress”:{“address”:“192.168.6.71”,“port”:3306}},“postion”:{“included”:false,“journalName”:“binlog.008335”,“position”:221691106,“serverId”:88888,“timestamp”:1524294834000}}}],“destination”:“example”}

default-instance.xml： 所有的组件(parser , sink , store)都选择了持久化模式，目前持久化的方式主要是写入zookeeper，保证数据集群共享。

        特点：支持HA

        场景：生产环境，集群化部署.

该模式会记录集群中所有运行的节点，主要用与HA主备模式，节点中的数据如下，可以关闭某一个canal服务来查看running的变化信息。

        然而问题来了，这样的测试环境不是我自己部署的吗？所以还真不是我部署的。