这两天参加了51CTO举办的云计算架构师峰会，办的非常好，很多干货。确实比一些名不副实的所谓大数据实际都是厂商推销产品的会议要强得多。但是其实这事跟Hadoop运维没关系，但是这两天集群发生的故障影响了我听报告。

说起来很奇幻，集群里面有三台服务器需要升级CPU，这本无可厚非。但是不多不少，恰恰是三台，符合Hadoop集群配置的replication数量。之间运维人员没有提前跟我们进行沟通，基本就是通知了一下，然后就瞬间停了3台服务器。这下坏了，整个集群基本就废了。存数据当然没问题，但是查数完全不能查了。之后最扯的事是OPS居然发现带错CPU了插不上去。等于白白废了集群，别的什么也没干。之后留守的数据组人员就发现集群无论如何也起不来了，只能打电话把我叫回来。

回到公司以后检查三台服务器无法启动的原因，其实起来了两台datanode和三台tasktracker，但无论什么样的reduce都做不了，会报错。另外有一台datanode无法启动。

一个一个解决吧。

一、解决tasktracker存在，但无法reduce的问题

看了一下50030的jobtracker页面，发现被停机的三台服务器主机名错误。被关机的服务器重新启动后，jobtracker里面的主机名列表有服务器名称变成了什么bta.net.cn。这明显是主机名被改了，hadoop在跟踪tasktracker的时候无法做内部的DNS解析，结果转到了外网的DNS上面。登上这三台服务器，发现果然bash提示符上显示的hostname被改掉了，变成了OPS自己起的名字叫什么web30。查看/etc/hosts文件，没有错误。那么用root账户执行 "hostname hadoop-node-xx"，用以将主机名改回原来的。退出root，再重新登录，切换root，主机名变更完成。

之所以要执行退出并重新登录。是因为，即使你在当前终端下变更了hostname，但这时在当前root终端下，仍然认为hostname是web30。这时即便你用hadoop账户启动hadoop，也会认为主机名是web30。所以必须退出当前TTY，重新切换root和hadoop，主机名才会正常。

修改主机名后，切换到hadoop用户，启动hadoop，正常启动。提示log文件为hadoop-hadoop-tasktracker-hadoop-node-xx.log。所以这里有个小技巧，查看hadoop创建的日志名字，是可以判断你是否正确设置了hostname。当然，绝对不能一下停3台。轮流停止3台服务器的tasktracker，并重新启动。jobtracker中的主机列表显示正常，reduce可以正常进行了。

二、解决单个datanode无法启动的问题。

这里分为两个小问题。

1. datanode曾错误的用root账户启动过，导致文件权限被变更。

经询问，OPS开机后，同事没有切换到hadoop用户启动datanode，而是在这个节点上用root账户启动的了datanode。发现弄错了之后，然后又停掉了切换到hadoop用户启动，就发现无法启动了。

通过观察日志发现，datanode日志大量报出Java.IO的exception，很乱，但究其根源，是访问blk_xxxx...块permission denied。所以立刻定位问题，是由于使用root账户启动，硬盘中的blk._xxxx..文件被置为了仅root用户读写权限造成的。于是在错误变更权限的硬盘上执行 "chown -R hadoop:hadoop *" 即可。重新启动datanode，正常启动。

2. 正常启动只能支持2-3分钟，然后datanode就又挂了。

先tail -f 打开datanode日志，然后启动datanode。日志大量报，Scheduling block blk_xxxx... but block is valid。大概是这话把，刷的太快记不清了。意思就是说，计划放置某某block，但是该block存在并合法，所以放弃。根据hadoop工作原理分析，是namenode需要往datanode上写入数据，但是分配的块名称在该节点上已经存在，并且数据校验合法，所以拒绝写入并放弃，同样的错误超过该datanode的容许范围，则挂掉了。那么问题也同样出在root账户启动上，root账户启动之后，正常工作了一段时间。并以root权限放置了一些block在硬盘上，问题1里面将这些block置为了hadoop权限。但namenode认为这些文件已经不存在了，所以需要replication，但是replication过程中发现这些文件又存在，并且合法。所以就挂掉了。

问题的解决就很简单了，删除掉一些报错的block文件，datanode正常启动没有问题。再做一下balance，集群又跑的嗖嗖的。

昨天解决完这些以后，特意叮嘱同事，我今天还需要参加51cto的云计算大会。一定要跟OPS说，明天不要停服务器，尽量周一我在的时候停。就算万不得已必须停，也千万不要再这么干了，万一非得这么干，也要一台一台停，每台确认没有问题了，再停下一台。

结果中午同事打电话，OPS又刚通知完就这样干了。倒是很给面子，没一下停三台，一下停了两台。然后同事又打电话说reduce做不了了，告知其hostname问题，遂正常解决。

30分钟全部搞完，我已经无力吐槽了，其实这根本不能算Hadoop的问题，完全属于人祸，管理和沟通的漏洞。