您好,登录后才能下订单哦!
这篇文章主要讲解了“基于TBDS的flume异常问题怎么排查”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“基于TBDS的flume异常问题怎么排查”吧!
长期运营中发现部署了flume集群的磁盘满,经过排查发现flume的日志目录导致。
具体看flume的大文件日志发现,某个MySQL相关的sink持续抛出异常,打印了大量的日志
根据这个异常信息(exception)即:
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after statement closed
字面意思为MySQL服务的状态(连接)已经关闭的状态下,仍然有提交事务操作,抛出了异常,但这个异常持续抛出,仍需要深入分析。
既然是flume抛出的,且与MySQL有关,那缩小问题范围,查找flume里谁在写MySQL。(flume的配置一般位于/etc/flume/conf/agent/flume.conf)
关闭阶段仅仅检查连接是否存在。
从sink的逻辑看,只有在空连接的情况下,sink状态才会是BACKOFF,其他情况下状态都是READY,且在向MySQL提交事务前后,不会检查连接状态,即使在SQL抛出异常的情况下也没有修改sink状态,导致提交抛出异常后,sink循环执行,循环抛出异常。这里就是不断抛出异常的根本。那么连接到底是什么时候关闭的呢?这里的原因猜测有2个:(1)sink长时间与MySQL没有交互,超过连接自动关闭时间;(2)MySQL的异常关闭。
是否sink长时间与MySQL无交互
查询MySQL的超时配置如下:
可见,sink与MySQL之间的断开并非二者长期无交互。
是否人为断开服务
查询人为启动MySQL的时间如下:
时间吻合。
结论
MySQL服务异常导致flume提交事务时连接中断,且flume没有处理这种异常,引发死循环提交事务,并在这种异常情况下,flume已无法正常工作。
根据以上的推论,可进行如下验证这个异常:
在HUE里执行多次HiveSQL
手动重启flume写入的MySQL实例。
flume进入无限循环的抛出异常状态,验证成功。
感谢各位的阅读,以上就是“基于TBDS的flume异常问题怎么排查”的内容了,经过本文的学习后,相信大家对基于TBDS的flume异常问题怎么排查这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是亿速云,小编将为大家推送更多相关知识点的文章,欢迎关注!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。