Hadoop运维12问--应急手册 - (EPUB全文下载)

文件大小：0.17 mb。
文件格式：epub 格式。
书籍内容：

Hadoop运维12问
——应急手册
向磊　著
本书由作者授权北京华章图文信息有限公司在全球范围内以网络出版形式出版发行本作品中文版，未经出版者书面许可，本书的任何部分不得以任何方式抄袭，翻录或翻印。
策划编辑：杜正彬　责任编辑：李静
封面设计：梁杰
客服热线：+ 86-10-68995265
客服信箱：service@bbbvip.com
官方网址：www.hzmedia.com.cn
新浪微博 @研发书局
腾讯微博 @yanfabook
目录
Hadoop运维记录系列(一)
Hadoop运维记录系列(二)
Hadoop运维记录系列(三)
Hadoop运维记录系列(四)
Hadoop运维记录系列(五)
Hadoop运维记录系列(六)
Hadoop运维记录系列(七)
Hadoop运维记录系列(八)
Hadoop运维记录系列(九)
Hadoop运维记录系列(十)
Hadoop运维记录系列(十一)
Hadoop运维记录系列(十二)
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，集群又运行正常了。
注意：不要瞬停多台服务器，就算万不得已必须停，也要一台一台停，每台确认没有问题了，再停下一台。
Hadoop运维记录系列(二)
本节主要讲解Hadoop的安装部署和运维部分，将平时工作中遇到的问题也提取了一下，希望能对Hadoop运维相关人员有所帮助，错误数据均来自以前日常工作中的Hadoop日志。
也有一点点跟Hadoop相关的非保密数据，拿出来晒晒。
目前公司的数据 ............

书籍插图：

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。