CDH集群常见故障处理

1 kudu在CDH的各个组件中最容易出现服务停止的情况

报错大部分原因是因为Clock init的问题，也就是时钟同步的问题，处理方法与hdfs的nfs gatway服务无法启动类似，手动同步一下时间即可：

      Servicentp stop

   Ntpdate CDH1

   Service ntp start

另外，集群因为断电之后重启，发现kudu组件的Tablet Server和Master大概率无法启动，一般来说，查看日志发现是Clock init方面的问题，只需要手动去同步节点上的系统时间就可以启动成功：

如果是FSLayout

failed，datachecksum Incorrect之类的错误，那就比较麻烦，这是因为断电的瞬间kudu还在写数据，导致数据块（data，metadata）损坏，里面的数据offset对不上，这种情况下，假如报错只发生在某一个节点上，那么把报错的数据块删除掉再重启服务即可，因为kudu默认配置了3备份，在节点宕机期间数据在集群中仍然有备份。假如报错发生在多个节点上，那么数据就很有可能丢失了，这种情况下的处理方案还有待考虑。

2安装nfs rpcbind

如果提示rpcbind没有安装，那么yum -y install nfs-utils即可

云平台的Centos没有自带NFS和RPCbind，需要yum -y install nfs rpcbind来安装之后才可正常启动hdfs

3

kafka启动失败的时候,可以看一下是不是分配给kafka的java

heap size太小的原因，修改一下java heap size，一般修改到1G以上

4离线安装spark的时候，要将一个Spark2_on_yarn的jar包放到每个节点的csd目录下，否则spark安装会报错。

5

hive需要将一个mysqlconnector的jar包放到/usr/local/java目录下

6重装kakfa的时候，提示启动失败，查看日志提示log.dir（/var/local/kafka/data)中有文件，要删除这个目录下的文件才可启动

7

hdfs的nfs gateway服务无法启动一般是因为rpcbind服务没有起来，到该服务对应的节点上service rpcbind start,然后service nfs stop即可

8在云平台上安装hdfs时会出现datanode启动时对config.zip的permission denied，修改java heap size之后，启动成功。

9如果HBase经常因为大数据量写入而导致Master服务宕机的话，可以考虑修改Hbase的GC机制，可以在CM管理页面中，HBase配置页下搜索“HBase Master的java配置选项”，在输入框中填写：

-XX:+UseG1GC -Xms32G -Xmx32G -XX:MaxGCPauseMillis=50 -XX:MaxTenuringThreshold=1-XX:G1HeapWastePercent=10 -XX:G1MixedGCCountTarget=16-XX:InitiatingHeapOccupancyPercent=65

然后重启HBase服务。

注意：在CM中做的任何配置修改，都要重启相应服务才能生效，某些关联到其他组件的配置还需要重启相关服务甚至重启集群。

10离线安装组件，以Spark2为例

在安装Spark2时，使用自己从Cloudera下载的parcel包做离线安装的话，要将Spark2的parcel包上传到主节点的/opt/parcels/目录下，然后将SPARK_ON_YARN-2.1.0.cloudera2.jar上传到/opt/cloudera/csd/目录下，然后在主节点上：

/opt/cm-5.11.1/etc/init.d/cloudera-scm-server restart

在每个节点上：

/opt/cm-5.11.1/etc/init.d/cloudera-scm-agent restart

必须要重启cloudera服务才能在CM添加服务页面找到Spark2的安装选项。