20210329学习笔记--看来得找个更新的视频课了（用IDEA），一步一步跟着做了，而且每天要定量，必须完成多少。目前进度完全不行。
感觉这样不行啊，一执行还是一大堆错，今天又浪费半天时间
继续执行写好的MapReduce程序，感觉用020304这三台比较好。
1.检查服务
node01
ResourceManager
NameNode
node02
NodeManager
DataNode
node03
DataNode
没了??
node04
DataNode
NodeManager
2.Web UI查看运行情况
扫盲下yarn，yarn其实就是mapreduce把调度这部分功能分离出来了，叫yarn，mapreduce自己现在只负责计算，而且yarn还可以用来调度其他计算框架。
hadoop 2.6.5/web UI访问
- hadoop, node01:50070（默认包括hdfs+mapreduce）
- yarn,node01:8088(job执行情况)
- jobhistoryserver,node01:19888
3.单节点手动启服务
集群总会有节点，某些组件挂掉，比如node03的nodeManager就没起来，手动起了一下好了。
启动各组件命令总结：
hdfs启动命令：
# 启动namenode
hadoop-daemon.sh start namenode
# 启动datanode，这个比较常用，因为可能会出现有的datanode没有起来
hadoop-daemon.sh start datanode
# 启动secondarynamenode
hadoop-daemon.sh start secondarynamenode
启动yarn命令:
# 启动resourcemanager
yarn-daemon.sh start resourcemanager
# 启动nodemanager
yarn-daemon.sh start nodemanager
启动历史服务器：
#启动历史服务器,一般的历史服务是肯定需要我们手动启动的
mr-jobhistory-daemon.sh start historyserver
4.MapReduce报错解决思路
首先应该是查日志，而不是去搜索报错，因为直接显示的报错都是表面原因。
其实我是看了datanode的日志才有报错。
Hadoop 2.x中YARN系统的服务日志包括ResourceManager日志和各个NodeManager日志，他们的日志位置如下：
ResourceManager日志：Hadoop安装目录下的logs目录下的yarn-*-resourcemanager-*.log
NodeManager日志：各个NodeManager节点上hadoop安装目录下的logs目录下的yarn-*-nodemanager-*.log
应用程序日志包括jobhistory日志和Container日志，其中，jobhistory日志是应用程序运行日志，包括应用程序启动时间、结束时间，每个任务的启动时间、结束时间，各种counter信息等。
Container日志包含ApplicationMaster日志和普通Task日志，它们均存放在Hadoop安装目录下的userlogs目录中的application_xxx目录下，其中ApplicationMaster日志目录名称为container_xxx_000001，普通task日志目录名称则为container_xxx_000002，container_xxx_000003，….，同Hadoop 1.x一样，每个目录下包含三个日志文件：stdout、stderr和syslog，且具体含义是一样的。
只查看最近100行日志
1）实时查看日志文件
tail -f 日志文件名（2）只查看日志文件后100行
tail -f -n 100 日志文件名（3）搜寻字符串
-
grep '搜寻字符串' 日志文件名
-
按ctrl+c 退出
5.查询错误
（1）mapreduce任务无法运行
datanode日志报错显示：java.net.NoRouteToHostException: 没有到主机的路由
解决方案：这问题首先是应该关闭防火墙
firewall-cmd --state
systemctl stop firewalld.service
但这还没完,SELINUX是Linux一个子安全机制
查看SeLinux状态：/usr/sbin/sestatus -v
将SELINUX=enforcing改为SELINUX=disabled
reboot重启机器
6.重启之后触发了新问题，namenode无法启动了。
报错为：Directory /tmp/hadoop-hadoop/dfs/name is in an inconsistent state
而我却并不是因为hadoop临时目录被清空，再次陷入迷茫。
rm -rf 彻底删除目录试试，也没用。
最后我觉得这是一个bug，我明明不是临时目录，不适合网上说的那种情况。我之前用hadoop2.6就发现了很多bug，只能忽略了，恢复一下快照。
然后SELinux，就临时关闭吧，以免重启再次造成这个问题。
临时关闭：
[root@localhost ~]# getenforce
Enforcing
[root@localhost ~]# setenforce 0
[root@localhost ~]# getenforce
Permissive
后记：看了下虚拟机好多文件还停留在2019年，回想起2019年半途而废的自己。
