- 博客(9)
- 收藏
- 关注
RSS订阅原创 CentOS7使用yum报错Could not resolve host: mirrorlist.centos.org； Unknown error（排查到凌晨）
然而我这里网络是正常的，然后在网上疯狂搜索，什么改/etc/resolv.conf文件、更改yum源、重装yum等等，这里我放一下我试过的方法。所以我做了一个大胆的决定，将CentOS-Base.repo文件外的所有文件全删掉，然后重置yum缓存，就相当于初始化yum的一个操作。总结一下，网上的解决方案基本上认为这个问题要么是DNS的问题，要么是yum源配置的问题，但是对我都没有效果.就在快要绝望的时候，敏锐的发现文件好像不对，这是出问题的那台机器的/etc/yum.repos.d文件夹。
2024-07-13 19:20:03
381
1
原创 java.net.NoRouteToHostException No route to host的排查与解决思路分享
那问题肯定就出在这个datanode22中了，经过简单的测试发现，在HiveSQL的执行过程中，hadoop的心跳时间经常很大，整个hadoop集群的心跳超时时间设置为600S(这个值设置的非常大，其实是有点不合理的)，在web页面上能看见该节点的last contact为三百多秒，和宕机差不多。其实这个问题以前也发生过，但是发生的频率是极其低的，导致不能复现，二是也没有太好的办法，就单单一个No route to host有点无从下手，所以一直以来都没有搞清楚到底是什么原因。
2023-11-26 20:33:40
3517
1
原创 Hivesql执行失败，Call From namenode2 to namenode2:10020 failed on connection排查与解决
在这里我的判断是第一种。因为我执行的SQL是解析json数据然后导入到表中，文件格式为lzo，51个文件总计大小3.8G，转成txt大概有15个G左右，而当时的stage-1阶段是4个map，1个reduce，所以导致这个问题。然而随着发生的次数增多，不能再继续无视下去了，并且直觉告诉我很有可能并不是预想的那么回事，所以深入研究下到底怎么回事。其实这种错误以前也时不时发生，但是正如报错所描述，我一直以为只是单纯的在任务执行中，资源吃紧造成卡顿而导致的，并且重新跑一次就好了，所以一直没当回事。
2023-11-25 17:10:49
184
原创 Dolphinscheduler伪集群模式下worker节点挂掉导致工作流一直运行的排查和解决过程
看到了这样的配置，基本上原因可以确定了，在部署海豚调度的节点上其实还有一些其他的服务，比如hive、namenode和resourcesmanager(这样确实很不合理)，这是非常吃资源的，但是没办法确实只有这点资源，所以导致hivesql一运行cpu高负载情况就会导致卡顿，而zookeeper设置超时时间600ms，这样出问题的概率那是百分百。该问题发生在hiveSQL的脚本执行过程中，sql跑着跑着worker进程就挂掉了，在之前也发生过好几次，但是一直没有重视都是重启就完事了。
2023-11-20 16:38:11
693
1
原创 记录一次使用dolphinScheduler连接clickhosue数据源connect failed的原因排查和解决
令人疑惑，这看着也没啥问题，于是进入日志查看原因，因为这并不是调度本身自己出问题，所以我们去/opt/module/dolphinscheduler/logs路径下查看dolphinscheduler-api.log日志文件。一看密码不对，我clickhouse内网部署也没有密码啊，再一看密码变成了123456，什么鬼？原因清楚了，应该是你不输入密码默认123456，然后我试图在下方的jdbc连接参数栏把密码输进去，结果还是不行。再进日志一看参数不合法。
2023-11-01 16:19:39
494
1
原创 记录一次HiveSQL执行中发生 GC overhead limit exceeded的解决过程
既然这样，那就关掉Hive默认开启的Combine，让一个map处理一个parquet文件，再给他6G的内存，这样应该是万无一失了。果然sql执行成功，看来就是因为parquet文件太大，导致需要大量内存，而默认combine的开启无疑会雪上加霜，几个parquet文件加起来需要超级大的内存。真是令人头疼，既然加内存不管用，那就试着将map数量增多，每个map处理的数据量少了，应该就能解决了。默认情况下，map和reduce阶段的内存都设置为2G（一般情况下都是够用的），运行一段时间后报错。
2023-10-16 21:22:31
537
原创 记录一次因HDFS小文件导致的HiveSQL异常耗时的问题排查和解决
可以发现同样的数据量，但是底层的存储文件完全不同，很明显就是小文件的问题，但是其中的差距太大了，难道小文件的破坏力这么强大？测试表明，两个分区两百多个小文件原来查询耗时一分多钟，导入sequencefile的表中查询耗时只有0.1秒，进入hdfs查看了一下两个分区只有四个文件，成功解决。到这里，问题基本上已经排查清楚了，至于怎么解决，方法是非常多的只要把文件数量减小就可以，我的解决方法是建一张sequencefile的表然后将数据导入。该表有370个分区，六万多个小文件。
2023-10-12 14:07:56
138
1
原创 org.apache.seatunnel.shade.com.typesafe.config.ConfigException$Parse
说实话这段注释极其具有误导性，read_partitions = [par1=xxx, par1=yyy/par2=zzz], it is illegal，那么普通人首先第一想法肯定是[par1=xxx, par1=yyy]才是正确的,就和下面这样。记录一个seatunnel的踩坑过程，使用环境为hive分区表导入click house中，首先查看官网的文档。看见错误代码，肯定是配置的问题，经过排查和网上搜索再加上不断试错，终于找到了正确的配置方法。
2023-09-07 21:09:41
478
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人