关于Hadoop重新格式化之后集群的崩溃问题
文章目录
- 关于Hadoop重新格式化之后集群的崩溃问题
- 写在前面
- 版本信息
- 实验场景
- Hive
- Hive交互段查询报错
- 原因分析
- 解决方法
- 手动启动元数据服务
- 重新初始化元数据库
- HBase
- 清理虚拟机磁盘
- 参考资料
写在前面
版本信息
- Linux版本:
CentOS7.5
- JDK版本:
JDK1.8
- Hadoop版本:
Hadoop-3.1.3
- MySQL版本:
MySQL5.7
- Hive版本:
Hive-3.1.2
- ZooKeeper版本:
ZooKeeper-3.5.7
- HBase版本:
HBase-2.0.5
- 环境:
完全分布式环境
(三台节点)
实验场景
VM Ware下搭建的虚拟机中,其中一台(hdp03)的磁盘空间占比远高于其他两台(hdp01<hdp02)虚拟机的磁盘空间占比。
清理步骤下文会提到,此处先看一下清理结果,如下图所示:
可以看到,虚拟机磁盘清理成功了。
Hive
Hive交互段查询报错
报错信息:FAILED: HiveException java.lang.RuntimeException: Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient
原因分析
无法启动元数据服务导致查询失败
解决方法
手动启动元数据服务
手动启动命令如下,启动后,重开一个shell窗口,进入到Hive交互端,重新查询
[whybigdata@hdp01 hive-3.1.2]$ hive --service metastore
- 有关元数据的配置文件是:hive-site.xml
<!-- 指定存储元数据要连接的地址 -->
<property><name>hive.metastore.uris</name><value>thrift://hdp01:9083</value>
</property>
重新初始化元数据库
如果手动启动元数据服务后还是出现相同的错误,那请尝试重新初始化元数据库
- 进入到MySQL客户端,删除metastor库,并重新创建metastore库
[yoona@hdp01 hive-3.1.2]$ mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 23
Server version: 5.7.28 MySQL Community Server (GPL)Copyright (c) 2000, 2019, Oracle and/or its affiliates. All rights reserved.Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| metastore |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.01 sec)mysql> drop database metastore;
.......
mysql> create database matestore;
- 执行初始化命令:
[whybigdata@hdp01 ~]$ sschematool -initSchema -dbType mysql -verbose
- 再次进入Hive客户端,查询即可
HBase
进程正常
报错信息如下:ERROR: org.apache.hadoop.hbase.PleaseHoldException: Master is initializing
查看日志:
hbase-whybigdata-master-hdp01.log
和hbase-whybigdata-regionserver-hdp01.log
都没有问题
重新彻底初始化
- 关闭hbase,删除hdfs的
/hbase
目录
删除目录之前,先
/hbase
目录的修改权限
[whybigdata@hdp01 hbase-2.0.5]$ bin/stop-hbase.sh
[whybigdata@hdp01 hadoop-3.1.3]$ bin/hdfs dfs chmod -R 777 /hbase
[whybigdata@hdp01 hadoop-3.1.3]$ bin/hdfs dfs -rm -r /hbase
修改权限前后:
- 删除ZooKeeper上的inode节点内容
/hbase
[whybigdata@hdp01 zookeeper-3.5.7]$ bin/zkCli.sh
[zk: localhost:2181(CONNECTED) 5] deleteall /hbase
- 重新zk集群,启动hbase,再次创建表即可成功
清理虚拟机磁盘
- 开启要进行磁盘清理的虚拟机,以root身份登录,执行以下命令
dd if=/dev/zero of=/0bits bs=20M
- 查看虚拟机磁盘可用空间,并执行删除命令
df -h
rm /0bits
- 关闭虚拟机
- 进入VMWare的安装路径(本人的是在D:\Program Files (x86)\VMware\VMware Workstation)在Windows命令行里执行下方命令
PS C:\Users\Administrator> cd d:
PS D:\> cd "d:\Program Files (x86)"
PS D:\Program Files (x86)>
PS D:\Program Files (x86)> cd '.\VMware\VMware Workstation\'
PS D:\Program Files (x86)\VMware\VMware Workstation>
PS D:\Program Files (x86)\VMware\VMware Workstation> .\vmware-vdiskmanager.exe -k "D:\VM\x.vmdk"Shrink: 100% done.
Shrink completed successfully.
此处当代时长大约3分半钟,可以看到,虚拟机磁盘再次清理成功!
- 关闭虚拟机,查看磁盘占比大小
清理虚拟机磁盘前后hdp03的占比大小如下图所示:
在前文也提到了磁盘清理成功,(由于参考资料中提到执行最后步骤等待的时间是比较长的)但是我在前问执行的步骤清理过程知识花费了20秒钟左右,就迅速地
100% done
了。
但是清理成功后,hdp03节点的大小也还是在25G的数值,这样的数值是hdp01的3倍,是hdp02的6倍多一点。我之所以质疑是因为,三台节点中hdp01的服务安装的是最多的,同时hdp02和hdp03的服务是相差无几的。
经过再一次的清理磁盘,还是在25G的数值,可能是虚拟机hdp03的无效文件多吧!
- 我还是不甘心,所以经过资料查找,我使用下面参考连接的一个方法进行「压缩虚拟机」
https://www.diskgenius.cn/exp/compressvirtualdisk.php
可是,最终还是没有改变,哈哈哈哈,彻底放弃了!
之所以不行,大概率是因为之前集群的hdp03节点由于磁盘空间不足被强制关机了,大概的描述就是:
在vmware中,hdp03接待你出现s001.vmdk的操作失败(磁盘空间不足),当时忘记截图了
这个问题在前面的文章讲过:
见文
参考资料
- http://t.csdn.cn/MEFBL
- https://www.diskgenius.cn/exp/compressvirtualdisk.php
全文结束!