CDH问题处理

现象：CDH所有服务报异常，HDFS提示存储空间为0；在CDH管理界面中能够看到集群中所有的主机，但是主机的信息看不到。

处理过程：

1）试图重启agent，但是所有的DataNode都提示agent正在运行

2）jps查看进程发现根本没有java进程在运行

3）运行cloudera-scm-agent status显示进程已死，但PID文件仍存

4）通过在cloudera-scm-agent脚本中输出PID文件名字，定位到PID文件

5）可以发现PID文件是个空文件，将PID文件删除

6）启动agent，发现可以启动了

7）将集群中所有的服务重启，过段时间后也都恢复正常了。

现象：CHD中HDFS报副本不足的块，经过排查，发现有一台DataNode起不来，日志中提示:org.apache.hadoop.util.DiskChecker$DiskErrorException: Too many failed volumes - current valid volumes: 3, volumes configured: 4, volumes failed: 1, volume failures tolerated: 0

处理过程：

1）原因很清楚，有一块硬盘坏了

2）搜索hdfs tolerated volume即可容忍坏掉的硬盘个数相关的配置项，将其改为1

3）改完后DataNode可以起来了，但是后续仍然需要及时更换掉坏掉的这块硬盘

现象：CDH一直报块丢失（块损坏），选择抑制后发现有些查询数据一直查不出来，也没报什么错误，只是查询超时，程序取数据时卡在ResultSet.next()中。

原因：抑制只是让警告不再报出来，块损坏对于查询的影响仍然存在。

解决方案：

查看损坏的块：

hdfs fsck -list-corruptfileblocks

自动修复

1）当数据块损坏后，DataNode节点执行directoryscan操作之前，都不会发现损坏；

默认是6小时扫描一次，配置项为dfs.datanode.directoryscan.interval : 21600

2）在DN向NN进行blockreport前，都不会恢复数据块;

默认为6小时执行一次，配置项为dfs.blockreport.intervalMsec : 21600000

当NN收到blockreport才会进行恢复操作。

2. 手动修复

hdfs debug recoverLease -path /blockrecover/blocktest.md -retries 10 # 重试10次

执行手动修复虽然成功了，但是检测损坏的块仍然可以检测出来，直接删除损坏的块：

hdfs fsck / -delete

执行完后再打开管理界面就不会报块丢失了，执行查询也没有问题，只是可能会丢失一段时间的数据。

参考：https://blog.csdn.net/weixin_44131414/article/details/100016728、

https://www.cnblogs.com/yinzhengjie/p/10923309.html

现象：向集群中增加了两台服务器，但是HBase RegionServer启动不了，查看角色日志，发现报了异常：Unhandled: Permission denied: user=hbase, access=WRITE, inode="/hbase/WALs"

解决方案：很明显是权限问题，查看/hbase/WALs的权限：

hdfs dfs -ls /hbase

可以看到目录的所有者为hdfs，对于hbase组其他用户只有读和执行的权限，这就可以解释上面报的错误了。对目录进行权限修改：

hdfs dfs -chmod 777 /hbase/WALs

再次尝试启动RegionServer就可以起来了。

phoenix查询超时问题

1、修改客户端配置hbase-site.xml：

配置参数	默认值
phoenix.query.timeoutMs	60000
hbase.rpc.timeout	60000
hbase.client.scanner.timeout.period	60000

由于客户端是使用的phoenix jar包，故直接在创建hbase连接的时候，传入配置：

Properties props = new Properties();
props.setProperty("phoenix.query.timeoutMs", "1200000");
props.setProperty("hbase.rpc.timeout", "1200000");
props.setProperty("hbase.client.scanner.timeout.period", "1200000");
	            
conn = DriverManager.getConnection(url, props);

2、修改服务端配置（在FusionInsight Manager上配置，需重启HBase）：

配置参数	默认值
hbase.rpc.timeout	60000
hbase.client.scanner.timeout.period	60000

使用的是CDH，直接在Cloudera manager管理界面，打开hbase配置后，修改上述两个配置。

修改后，提示应小于zookeeper的session 超时时间，故将zookeeper的session timeout也进行修改。

3、修改后进行测试，发现已经能够执行查询时间很长的SQL

4、这个只是暂时解决目前这个数据量下的超时，如果以后数据量增大，这个超时有可能也还要继续调整，由于这个超时跟数据量数据结构等都有关联，暂时还无法给出一个定量的建议值。

参考：

https://blog.csdn.net/u013850277/article/details/80935545

http://support-it.huawei.com/docs/zh-cn/fusioninsight-all/maintenance-guide/zh-cn_topic_0035061040.html

https://blog.csdn.net/u013850277/article/details/80935545

猜你喜欢