1.Namenode的平安模式？

平安模式是Namenode的一种状态（Namenode次要有active/standby/safemode三种模式）。

2.哪些状况下，Namenode会进入平安模式？

a. Namenode发现集群中的block失落率达到肯定比例时（默认0.01%），大数据培训Namenode就会进入平安模式，在平安模式下，客户端不能对任何数据进行操作，只能查看元数据信息

b. 在hdfs集群失常冷启动时，Namenode也会在safemode状态下维持相当长的一段时间，此时你不须要去理睬，期待它主动退出平安模式即可

3.为什么，在HDFS集群冷启动时，Namenode会在平安模式下维持相当长的一段时间？

Namenode的内存元数据中，蕴含文件门路、正本数、blockid，及每一个block所在Datanode的信息，而fsimage中，不蕴含block所在的Datanode信息。那么，当Namenode冷启动时，此时内存中的元数据只能从fsimage中加载而来，从而就没有block所在的Datanode信息 ——> 就会导致Namenode认为所有的block都曾经失落 ——> 进入平安模式 ——> 所在的Datanode信息启动后，会定期向Namenode汇报本身所持有的block信息 ——> 随着Datanode陆续启动，从而陆续汇报block信息，Namenode就会将内存元数据中的block所在Datanode信息补全更新 ——> 找到了所有block的地位，从而主动退出平安模式

4.如何退出平安模式？

1）找到问题所在，进行修复（比方修复宕机的所在Datanode信息补全更新）

2）能够手动强行退出平安模式：hdfs namenode --safemode leave 【不举荐，毕竟没有真正解决问题】

5.Namenode服务器的磁盘故障导致namenode宕机，如何解救集群及数据？

1）HA机制：高可用hadoop2.0
2）配置hdfs-site.xml指定而后重启Namenode运行时数据寄存多个磁盘地位
3）而后重启Namenode和SecondaryNamenode的工作目录存储构造完全相同，当然后重启Namenode故障退出须要从新复原时，能够从SecondaryNamenode的工作目录存储构造完全相同，当的工作目录中的namesecondary文件夹及其中文件拷贝到而后重启Namenode所在节点工作目录中(但只能复原大部分数据SecondaryNamenode最初一次合并之后的更新操作的元数据将会失落)，将namesecondary重命名为name而后重启Namenode

6.Namenode是否能够有多个？Namenode跟集群数据存储能力有关系吗？

1）非HA的模式下Namenode只能有一个，HA模式下能够有两个（一主active一备standby），HDFS联邦机制能够有多个Namenode

2）关系不大，存储数据由Datanode实现。然而药尽量避免存储大量小文件，因为会消耗Namenode内存

7.fsimage是否寄存了block所在服务器信息？
1）在edits中保留着每个文件的操作详细信息

2）在fsimage中保留着文件的名字、id、分块、大小等信息，然而不保留Datanode 的IP

3）在hdfs启动时处于平安模式，Datanode 向Namenode汇报本人的IP和持有的block信息

平安模式完结，文件块和Datanode 的IP关联上

验证过程：

1) 启动Namenode，来到safemode，cat某个文件，看log，没有显示文件关联的Datanode

2) 启动Datanode，cat文件，内容显示

3) 进行Datanode ，cat文件，看log，看不到文件，但显示了文件块关联的Datanode

8.Datanode动静高低线？

在理论生产环境中，在hdfs-site.xml文件中还会配置如下两个参数：

dfs.hosts：白名单；dfs.hosts.exclude：黑名单

<name>dfs.hosts</name>

残缺的文件门路：列出了容许连入NameNode的datanode清单（IP或者机器名）

<value>$HADOOP_HOME/conf/hdfs_include</value>

</property>

<name>dfs.hosts.exclude</name>

<value>$HADOOP_HOME/conf/hdfs_exclude</value>

</property>

1) 上线datanode

a) 保障上线的datanode的ip配置在白名单并且不呈现在黑名单中

b) 配置胜利上线的datanode后，通过命令hadoop-daemon.sh datanode start启动

c) 刷新节点状态：/bin/hadoop dfsadmin -refreshNodes(这个命令能够动静刷新dfs.hosts和dfs.hosts.exclude配置，无需重启NameNode)

d) 手动进行数据平衡：start-balance.sh

2) 下线datanode

a) 保障下线的datanode的ip配置在黑名单并且不呈现在白名单中

b) 敞开下线的节点

c) 刷新节点状态：/bin/hadoop dfsadmin -refreshNodes

d) 机器下线结束后，将它们从hdfs_exclude文件中移除

9.对于Datanode的几个问题？
1）Datanode在什么状况下不会备份？
在强制敞开或者非正常断电时不会备份

2）3个Datanode中有一个Datanode呈现谬误会怎么？

这个Datanode的数据会在其余的Datanode上从新做备份

10.HDFS HA机制下的脑裂景象以及防止办法？

当standby Namenode的ZKFailoverController收到active Namenode端故障告诉时，不会立刻将本人的状态切换为active，因为此时active Namenode可能处于“假死”状态，如果即刻切换为active状态，有可能造成脑裂景象。

为了避免脑裂，倡议写个脚本确保收回故障告诉的active Namenode肯定被kill掉，具体能够依照以下几个步骤实现kill操作：
1.执行杀掉active Namenode的shell脚本，期待ssh kill返回命令
2.如果响应胜利，就把原standby Namenode的状态切换为active；如果响应失败或者超时（能够配置一个超时工夫）
3.只有shell脚本的调用返回值为true，则切换本人端的Namenode状态为active

11.HDFS为什么不适宜存储小文件？

个别一个block对应的元数据大小为150byte左右，大量小文件会使内存中的元数据变大导致占用大量Namenode内存、寻址工夫长

12.大量小文件的解决形式？

1）打成HAR files
命令：hadoop archive -archiveName xxx.har -p /src /dest
查看内容：hadoop fs -lsr har:///dest/xxx.har

该命令底层实际上是运行了一个MapReduce工作来将小文件打包成HAR。然而通过HAR来读取一个文件并不会比间接从HDFS中读取文件高效，因为对每一个HAR文件的拜访都须要进行index文件和文件自身数据的读取。并且尽管HAR文件能够被用来作为MapReduce工作的input，然而并不能将HAR文件中打包的文件当作一个HDFS文件解决

2）编写MR程序，将小文件序列化到一个Sequence File中

将小文件以文件名作为key，以文件内容作为value，编写一个程序将它们序列化到HDFS上的一个Sequence File中，而后来解决这个Sequence File。绝对打成HAR文件，具备两个劣势：
（1）Sequence File是可拆分的，因而MapReduce能够将它们分成块并独立地对每个块进行操作
（2）它们同时反对压缩，不像HAR。在大多数状况下，块压缩是最好的抉择，因为它将压缩几个记录为一个块，而不是一个记录压缩一个块

13.查看HDFS集群工作状态命令？

hdfs dfsadmin -report：疾速定位各个节点状况，如每个节点的硬盘应用状况