记一次hadoop磁盘空间满的错误
记一次hadoop磁盘空间满的异常
本事故，发生在测试的环境上，虽然不是线上的环境，但也是一次比较有价值的事故。
起因：公司里有hadoop的集群，用来跑建索引，PHP使用人员，调用建索引的程序时，发现MapReduce集群启动不起来了，报IOException异常，具体的异常没有记录，大致的意思就是磁盘空间满了，导致创建文件失败！
下面散仙模拟当时的环境，接到问题后，第一件事就是先查看centos系统的磁盘使用率
执行命令 df -h ，查看当前占用情况：
发现磁盘使用100%，导致空间不足，从而使Hadoop启动作业时的，需要建立临时的文件的空间都没有，故出现了，文章开头的一幕。
找到原因后，就好办了，查看当前系统下文件占用情况，删除几个比占空间比较大而且无关紧要的文件，当然我们这是在测试的环境上，一般线上挂载的磁盘都比较大，出现这样的异常情况，应该非常小。
执行命令： ll -h 查看某些文件目录的大小
这个命令散仙测，某些时候，不太好使，故使用下面命令
du -sh * 查看空间文件占用情况：
删除几个文件后，磁盘率达到一个启动MR作业的要求，然后再次运行MR作业时，发现又报异常，看log发现，Hadoop由于磁盘满，而导致进入安全模式，所以导致提交失败，异常如下：
知道原因后，执行如下命令，退出安全模式
hadoop dfsadmin -safemode leave
再次提交MR作业后，正常运行！
总结：
1，遇到问题时，第一反应，尽可能的先把原始信息，异常什么的保留下来，便于分析，有的可能没有log记录，或者log比较大查找不方便，用手机拍照，或粘贴复制什么的。
2，根据异常信息，尽可能直接准确异常的原因，如果实在定位不到，可能还需要分析最近几天系统里发生的变化，然后一个个定位，排除。
3，解决成功后，尽可能记录下来，发生的原因是什么，然后排除的方法，等等一些心得体会，最后，分享给团队或同事，避免以后发生此种类似的事，或者发生后，便于快速根据文档恢复，这一点非常重要。
本事故，发生在测试的环境上，虽然不是线上的环境，但也是一次比较有价值的事故。
起因：公司里有hadoop的集群，用来跑建索引，PHP使用人员，调用建索引的程序时，发现MapReduce集群启动不起来了，报IOException异常，具体的异常没有记录，大致的意思就是磁盘空间满了，导致创建文件失败！
下面散仙模拟当时的环境，接到问题后，第一件事就是先查看centos系统的磁盘使用率
执行命令 df -h ，查看当前占用情况：
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root
11G 8.7G 1.3G 100% /
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/sda1 485M 37M 423M 8% /boot
发现磁盘使用100%，导致空间不足，从而使Hadoop启动作业时的，需要建立临时的文件的空间都没有，故出现了，文章开头的一幕。
找到原因后，就好办了，查看当前系统下文件占用情况，删除几个比占空间比较大而且无关紧要的文件，当然我们这是在测试的环境上，一般线上挂载的磁盘都比较大，出现这样的异常情况，应该非常小。
执行命令： ll -h 查看某些文件目录的大小
这个命令散仙测，某些时候，不太好使，故使用下面命令
du -sh * 查看空间文件占用情况：
[search@bjdevfse02 ~]$ du -sh * 4.0K beginzk.sh 4.0K clearhadoop.sh 0 hadoop 95M hadoop-1.2.1 214M hadoop-2.2.0 152K hadoopconf 345M hadoop-dd 4.0K script 0 solr 188M solr-4.3.0 52M solr-4.3.1 704K solrconf 4.0K stopzk.sh 4.0K synconf.sh 36K tmp 0 zk 8.0K zkconf 39M zkdata 40M zookeeper-3.4.5 4.0K zookeeper.out
删除几个文件后，磁盘率达到一个启动MR作业的要求，然后再次运行MR作业时，发现又报异常，看log发现，Hadoop由于磁盘满，而导致进入安全模式，所以导致提交失败，异常如下：
知道原因后，执行如下命令，退出安全模式
hadoop dfsadmin -safemode leave
再次提交MR作业后，正常运行！
总结：
1，遇到问题时，第一反应，尽可能的先把原始信息，异常什么的保留下来，便于分析，有的可能没有log记录，或者log比较大查找不方便，用手机拍照，或粘贴复制什么的。
2，根据异常信息，尽可能直接准确异常的原因，如果实在定位不到，可能还需要分析最近几天系统里发生的变化，然后一个个定位，排除。
3，解决成功后，尽可能记录下来，发生的原因是什么，然后排除的方法，等等一些心得体会，最后，分享给团队或同事，避免以后发生此种类似的事，或者发生后，便于快速根据文档恢复，这一点非常重要。