Otter遇到的问题

Posted on 2019-06-12 Edited on 2024-12-07 In otter

1. biglog文件被清理

1.1 报错日志  
1
Could not find first log file name in binary log index file

1.2 现象  

pipeline的mainstem状态 一直处于定位中状态

1.3 问题排查  
一般出现这个报错，都是由于清空数据库binlog文件导致（自动清除biglog），我们按下述步骤确定是否由于binlog文件被清理：  

首先，查看当前同步的binlog位点;  
其次，登录数据库查看binlog信息（show master logs）；
最后，对比位点信息就能发现biglog丢失；

1.4 处理方法

1）通道停止增量同步；  
2）清空掉otter的同步信息；  
3）检查canal的同步位点信息；  
4）重新启动otter同步；

2. mysql大事物造成otter假死

2.1 报错日志  
    无报错日志

2.2 现象  
    channel状态正常，mainstrm状态正常，但是position信息里，position的信息一直不更新（超过半小时以上）

2.3 问题排查  
    确认是否为大事物的方法  
    1）查询数据库当前位点信息（show master logs）；
    2）查询位点的详细信息（show binlog events in 'binlog名称'）；
    3）查看binlog日志中begin和commit的偏移量相差多大即可；
    
2.4 处理方法
    1）清空掉otter同步信息；
    2）检查canal的同步位点配置；
    3）重新启动otter同步；

3. node节点内存溢出

3.1 报错日志
1
java.lang.OutOfMemoryError: unable to create new native thread


3.2 现象  
node节点均为运行状态，但是涉及到问题node的channel同步处于挂起状态，且无法解挂及停止；

3.3问题排查  
1）根据报错log找到对应的node节点；
2）查看该node节点的日志找到该报错日志；

3.4处理方法   
1）重启node节点；

4. node节点挂掉

4.1 现象  
Channel配置显示为挂起或者停止状态，并且启动或者解挂操作置灰不可操作，可以判定为node节点挂了。

4.2 问题排查  
进入node管理页面，查看是否有node节点处于未启动状态；

4.3 处理方法  
1） 重启node节点

5. otter网络故障

5.1 报错日志  
1
2
3
4
5
6
7
8
pid:14 nid:1 exception:canal:dataplatform:com.alibaba.otter.canal.parse.exception.CanalParseException: java.io.IOException: connect /192.168.116.16:3306 failure
Caused by: java.io.IOException: connect /192.168.116.16:3306 failure
 at com.alibaba.otter.canal.parse.driver.mysql.MysqlConnector.connect(MysqlConnector.java:77)
 at com.alibaba.otter.canal.parse.inbound.mysql.MysqlConnection.connect(MysqlConnection.java:86)
 at com.alibaba.otter.canal.parse.inbound.mysql.MysqlEventParser.preDump(MysqlEventParser.java:85)
 at com.alibaba.otter.canal.parse.inbound.AbstractEventParser$3.run(AbstractEventParser.java:175)
 at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.ConnectException: Connection timed out (Connection timed out)


5.2 现象
channel同步处于挂起状态，解挂后有开始挂起状态；

5.3 问题排查
查看对应的node日志，是否数据库连接失败；

5.4 处理方法
联系dba处理；

6.数据源ip变更处理方法

6.1 现象
生产环境下，偶尔会因为主备设置或者ip规划导致需要更改同步的数据源ip。

6.2 处理方法
1）Channel停止同步；
2）记录binlog的同步进度；
3）修改对应canal的数据源地址；
4）删除当前同步位点信息；
5）重新开启同步；

7.日志列表中出现miss data with keys异常，同步出现挂起后又自动恢复

7.1 报错日志
1
pid:2 nid:2 exception:setl:load miss data with keys:[MemoryPipeKey[identity=Identity[channelId=1,pipelineId=2,processId=4991953],time=1383190001987,dataType=DB_BATCH]]

7.2 处理方式
要理解该异常，需要先了解一下otter调度模型，里面SEDA中多个stage之间通过pipe进行数据交互，
比如T模块完成后会将数据存到pipe中，然后通知SEDA中心，中心会通知L模块起来工作，
L模块就会根据T传给中心的pipeKey去提取数据，而该异常就是当L模块根据pipeKey去提取数据时，发现数据没了。 主要原因：pipe在设计时，如果是单机传输时，会使用softReference来存储，
所以当jvm内存不足时就会被GC掉，所以就会出现无数据的情况.

ps. 如果miss data with keys异常非常多的时候，你就得考虑是否当前node已经超负载运行，内存不够，
需要将上面的部分同步任务迁移出去。如果是偶尔的异常，那可以忽略，该异常会有自动恢复RESTART同步任务的处理。

8.日志列表中出现manager异常

8.1 报错日志
1
2
3
4
5
6
7
8
pid:2 nid:null exception:channel:can't restart by no select live node
//该异常代表pipelineId = 2，select模块的node没有可用的节点.

pid:-1 nid:null exception:cid:2 restart recovery successful for rid:-1
//该异常代表channelId = 2，成功发起了一次restart同步任务的操作.

pid:-1 nid:null exception:nid:2 is dead and restart cids:[1,2]
//该异常代表node id = 2，因为该node挂了，触发了channelId = 1 / 2的两个同步任务发起restart同步任务的操作. (一种failover的机制)

8.2 处理方式
无需处理