hadoop大数据(七)-HDFS的Namenode和Datanode

发表于 | 分类于
字数统计: 6,915 | 阅读时长 ≈ 29

五 NameNode工作机制

5.1 NameNode&Secondary NameNode工作机制

img

1）第一阶段：namenode启动

（1）第一次启动namenode格式化后，创建fsimage和edits文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存（初始化系统为上一次退出时的最新状态）。

（2）客户端对元数据进行增删改的请求

（3）namenode记录操作日志，更新滚动日志。

（4）namenode在内存中对数据进行增删改查

对于namenode而言最新的操作日志是 edits.in.progress(正在执行的日志)

2）第二阶段：Secondary NameNode工作

核心工作：检查是否需要合并namenode的编辑日志和镜像文件（checkpoint）

​ （1）Secondary NameNode询问namenode是否需要checkpoint。直接带回namenode是否检查结果。定时时间默认1小时，edits默认一百万次

​ （2）Secondary NameNode请求执行checkpoint。（是否需要合并两个文件）

​ （3）namenode滚动正在写的edits日志（edits.in.progress）

​ （4）将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode

​ （5）Secondary NameNode加载编辑日志和镜像文件到内存，并合并。

​ （6）生成新的镜像文件fsimage.chkpoint

​ （7）拷贝fsimage.chkpoint到namenode

​ （8）namenode将fsimage.chkpoint重新命名成fsimage

也就是说，secondarynamenode的主要作用是帮助namenode分担他的压力，主要是帮助namenode合并镜像和操作日志，合并后，推给namenode。

总结

正如上面所分析的，Hadoop文件系统会出现编辑日志（edits）不断增长的情况，尽管在NameNode运行期间不会对文件系统造成影响，但是如果NameNode重新启动，它将会花费大量的时间运行编辑日志中的每个操作，在此期间也就是我们前面所说的安全模式下，文件系统是不可用的。
为了解决上述问题，Hadoop会运行一个Secondary NameNode进程，它的任务就是为原NameNode内存中的文件系统元数据产生检查点。其实说白了，就是辅助NameNode来处理fsimage文件与edits文件的一个进程。它从NameNode中复制fsimage与edits到临时目录并定期合并成一个新的fsimage并且删除原来的编辑日志edits。具体 步骤如下：
（1）Secondary NameNode首先请求原NameNode进行edits的滚动，这样会产生一个新的编辑日志文件edits来保存对文件系统的操作（例如：上传新文件，删除文件，修改文件）。
（2）Secondary NameNode通过Http方式读取原NameNode中的fsimage及edits。
（3）Secondary NameNode将fsimage及edits进行合并产生新的fsimage
（4）Secondary NameNode通过Http方式将新生成的fsimage发送到原来的NameNode中
（5）原NameNode用新生成的fsimage替换掉旧的fsimage文件，新生成的edits文件也就是（1）生成的滚动编辑日志文件替换掉之前的edits文件

3）web端访问SecondaryNameNode

​ （1）启动集群

​ （2）浏览器中输入：http://hadoop102:50090/status.html

​ （3）查看SecondaryNameNode信息

img

4）chkpoint检查时间参数设置

（1）通常情况下，SecondaryNameNode每隔一小时执行一次。

​ [hdfs-default.xml]

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>3600</value>
</property>

（2）一分钟检查一次操作次数，当操作次数达到1百万时，SecondaryNameNode执行一次。

<property>
  <name>dfs.namenode.checkpoint.txns</name>
  <value>1000000</value>
<description>操作动作次数</description>
</property>
<property>
  <name>dfs.namenode.checkpoint.check.period</name>
  <value>60</value>
<description> 1分钟检查一次操作次数</description>
</property>

5.2 镜像文件和编辑日志文件

1）概念

​ namenode被格式化之后，将在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目录中产生如下文件

edits_0000000000000000000 fsimage_0000000000000000000.md5 seen_txid VERSION

（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。

（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。

（3）seentxid文件保存的是一个数字，就是最后一个edits的数字（最后一次操作的序号）

（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。

2）oiv查看fsimage文件

（1）查看oiv和oev命令

[kingge@hadoop102 current]$ hdfs

oiv apply the offline fsimage viewer to an fsimage

oev apply the offline edits viewer to an edits file

（2）基本语法

hdfs oiv -p 文件类型 -i镜像文件 -o 转换后文件输出路径

（3）案例实操

[kingge@hadoop102 current]$ pwd

/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current

[kingge@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml

[kingge@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/fsimage.xml

将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

img

​ 总结

查看XML你会发现，里面存储了HDFS中文件或者文件夹的创建日期，权限，名称等等元数据信息。但是并没有存储文件保存的位置，也就是：并没有发现文件存储的DataNode节点信息信息那么当客户端请求读数据的时候，namenode是怎么返回数据所在块信息呢？原来他会一直跟datanode进行交互，获取数据所在块信息。

3）oev查看edits文件

edits包括两类，edits_XXX,edits_inprogress_XXX

edits_XXX：保存文件系统的操作，查看方式见下面语法
<?xml version="1.0" encoding="UTF-8"?>
-<EDITS>
<EDITS_VERSION>-63</EDITS_VERSION>
-<RECORD>
<OPCODE>OP_START_LOG_SEGMENT</OPCODE>
-<DATA>
<TXID>7170</TXID>
</DATA>
</RECORD>
-<RECORD>
<OPCODE>OP_ADD</OPCODE>
-<DATA>
<TXID>7171</TXID>
<LENGTH>0</LENGTH>
<INODEID>17787</INODEID>
<PATH>/user/zpx/a.txt</PATH>
<REPLICATION>3</REPLICATION>
<MTIME>1489118864779</MTIME>
<ATIME>1489118864779</ATIME>
<BLOCKSIZE>数据的大小</BLOCKSIZE>
<CLIENT_NAME>DFSClient_NONMAPREDUCE_1295720148_1</CLIENT_NAME>
<CLIENT_MACHINE>192.168.231.1</CLIENT_MACHINE>
<OVERWRITE>true</OVERWRITE>
-<PERMISSION_STATUS>
<USERNAME>Administrator</USERNAME>
<GROUPNAME>supergroup</GROUPNAME>
<MODE>420</MODE>
</PERMISSION_STATUS>
<RPC_CLIENTID>0c9a5af9-26a8-45d9-8754-cd0e7e47f65b</RPC_CLIENTID>
<RPC_CALLID>0</RPC_CALLID>
</DATA>
</RECORD>
</EDITS>
对Hdfs文件系统的每一个操作都保存在了edits文件中，每一个操作都是事务，有事务id——<TXID>7171</TXID>，还有当前操作做了什么<OPCODE>OP_ADD</OPCODE>，副本数，以及大小
edits_inprogress_XXX：正在使用的过程，当前正在向前滚动。查看方式见下面语法

（1）基本语法

hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径

（2）案例实操

[kingge@hadoop102 current]$ hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml

[kingge@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/edits.xml

将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。

总结

img

你会发现，edits_inprogress，记录的是当前客户端请求执行的操作（增量记录当前操作）

5.3 滚动编辑日志

正常情况HDFS文件系统有更新操作时，就会滚动编辑日志。也可以用命令强制滚动编辑日志。

1）滚动编辑日志（前提必须启动集群）

[kingge@hadoop102 current]$ hdfs dfsadmin -rollEdits

2）镜像文件什么时候产生

Namenode启动时加载镜像文件和编辑日志

1560169952390

5.4 Namenode版本号

1）查看namenode版本号

在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current这个目录下查看VERSION

namespaceID=1933630176

clusterID=CID-1f2bf8d1-5ad2-4202-af1c-6713ab381175

cTime=0

storageType=NAME_NODE

blockpoolID=BP-97847618-192.168.10.102-1493726072779

layoutVersion=-63

2）namenode版本号具体解释

（1） namespaceID在HDFS上，会有多个Namenode，所以不同Namenode的namespaceID是不同的，分别管理一组blockpoolID。

（2）clusterID集群id，全局唯一

（3）cTime属性标记了namenode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

（4）storageType属性说明该存储目录包含的是namenode的数据结构。

（5）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。

（6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

5.5 SecondaryNameNode目录结构

Secondary NameNode用来监控HDFS状态的辅助后台程序，每隔一段时间获取HDFS元数据的快照。

1560170177897

也即是说存在两种情况secondarynamenode会向namenode请求合并镜像文件和日志文件。（1）当上次请求时间已经间隔了一个小时后，会去请求（2）当操作数（edits，操作日志数）到达一百万次时，会去请求
那么他怎么知道操作次数到达一百万次呢？答案是，一分钟请求namenode一次，查询操作次数是否到达一百万次。注意，这个检查操作数的时间设置最好不要跟img

一致，不然他会默认执行第一种场景（间隔一个小时）

1560170270685

在/opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/current这个目录中查看SecondaryNameNode目录结构。

edits_0000000000000000001-0000000000000000002 fsimage_0000000000000000002 fsimage_0000000000000000002.md5 VERSION

SecondaryNameNode的namesecondary/current目录和主namenode的current目录的布局相同。

好处：在主namenode**发生故障时（假设没有及时备份数据），可以从SecondaryNameNode**恢复数据。

根据secondarynamenode恢复namenode

方法一：将SecondaryNameNode中数据拷贝到namenode存储数据的目录；

方法二：使用-importCheckpoint选项启动namenode守护进程，从而将SecondaryNameNode中数据拷贝到namenode目录中。

1）案例实操（一）：

模拟namenode故障，并采用方法一，恢复namenode数据

（1）kill -9 namenode进程

（2）删除namenode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）

[kingge@hadoop102 hadoop-2.7.2]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*

（3）拷贝SecondaryNameNode中数据到原namenode存储数据目录

​ [kingge@hadoop102 hadoop-2.7.2]$ scp -R /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/* /opt/module/hadoop-2.7.2/data/tmp/dfs/name/

（4）重新启动namenode

[kingge@hadoop102 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start namenode

2）案例实操（二）：

模拟namenode故障，并采用方法二，恢复namenode数据

（0）修改hdfs-site.xml中的

<property>
  <name>dfs.namenode.checkpoint.period</name>
  <value>120</value>
</property>
#  120秒checkpoint一次
<property>
  <name>dfs.namenode.name.dir</name>
  <value>/opt/module/hadoop-2.7.2/data/tmp/dfs/name</value>
</property>
# namenode镜像文件和操作日志存放目录

（1）kill -9 namenode进程

（2）删除namenode存储的数据（/opt/module/hadoop-2.7.2/data/tmp/dfs/name）

[kingge@hadoop102 hadoop-2.7.2]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/name/*

（3）如果SecondaryNameNode不和Namenode在一个主机节点上，需要将SecondaryNameNode存储数据的目录拷贝到Namenode存储数据的平级目录。Scp命令拷贝过来

1560170458431

  
[kingge@hadoop102 dfs]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs
[kingge@hadoop102 dfs]$ ls
data  name  namesecondary

（4）导入检查点数据（等待一会ctrl+c结束掉）

[kingge@hadoop102 hadoop-2.7.2]$ bin/hdfs namenode -importCheckpoint

（5）启动namenode

[kingge@hadoop102 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start namenode

（6）如果提示文件锁了，可以删除in_use.lock

​ [kingge@hadoop102 hadoop-2.7.2]$ rm -rf /opt/module/hadoop-2.7.2/data/tmp/dfs/namesecondary/in_use.lock

5.5.5 设置checkpoint检查时间

默认的checkpoint period是1个小时。可以去hdfs-site.xml中修改

1560170515392

5.6 集群安全模式操作

1）概述

Namenode启动时，首先将映像文件（fsimage）载入内存，并执行编辑日志（edits）中的各项操作。一旦在内存中成功建立文件系统元数据的映像，则创建一个新的fsimage文件和一个空的编辑日志。此时，namenode开始监听datanode请求。但是此刻，namenode运行在安全模式，即namenode的文件系统对于客户端来说是只读的。（可以解释为什么在namenode启动的时候，我们put数据到hdfs会提示，安全模式错误）因为这个时候namenode和datanode还没有联通对方，需要等待连通后，安全模式自动关闭，然后就可以上传文件了

系统中的数据块的位置并不是由namenode维护的，而是以块列表的形式存储在datanode中。在系统的正常操作期间，namenode会在内存中保留所有块位置的映射信息。在安全模式下，各个datanode会向namenode发送最新的块列表信息，namenode了解到足够多的块位置信息之后，即可高效运行文件系统。

如果满足“最小副本条件”，namenode会在30秒钟之后就退出安全模式。所谓的最小副本条件指的是在整个文件系统中99.9%的块满足最小副本级别（默认值：dfs.replication.min=1）。在启动一个刚刚格式化的HDFS集群时，因为系统中还没有任何块，所以namenode不会进入安全模式。

2）基本语法

集群处于安全模式，不能执行重要操作（写操作）。集群启动完成后，自动退出安全模式。

（1）bin/hdfs dfsadmin -safemode get （功能描述：查看安全模式状态）

（2）bin/hdfs dfsadmin -safemode enter （功能描述：进入安全模式状态）

（3）bin/hdfs dfsadmin -safemode leave （功能描述：离开安全模式状态）

（4）bin/hdfs dfsadmin -safemode wait （功能描述：等待安全模式状态）

3）案例

​ 模拟等待安全模式

​ 1）先进入安全模式

[kingge@hadoop102 hadoop-2.7.2]$ bin/hdfs dfsadmin -safemode enter

​ 2）执行下面的脚本

编辑一个脚本

#!/bin/bash
bin/hdfs dfsadmin -safemode wait
bin/hdfs dfs -put ~/hello.txt /root/hello.txt

​ 3）再打开一个窗口，执行

[kingge@hadoop102 hadoop-2.7.2]$ bin/hdfs dfsadmin -safemode leave

5.7 Namenode多目录配置

1）namenode的本地目录可以配置成多个，且每个目录存放内容相同，增加了可靠性。

2）具体配置如下：

​ hdfs-site.xml

<property>
    <name>dfs.namenode.name.dir</name>
<value>file:///${hadoop.tmp.dir}/dfs/name1,file:///${hadoop.tmp.dir}/dfs/name2</value>
</property>
 2.停止集群，删除数据文件 --  rm -rf data/logs (集群里有多少台服务器就删除多少台)
3.格式化namenode
4.调用xsync 分发脚本到各个集群 
5.启动集群
6.查看设置的本地目录name1、name2 你会发现里面的数据一模一样

测试NameNode

场景：关闭namenode（stop-dfs.sh），关闭yarn（stop-yarn.sh），删除hadoop目录下的data目录和log目录。

1.格式化namenode – bin/hdfs namenode -format

2.启动hdfs和yarn

六 DataNode工作机制

6.1 DataNode工作机制

1560170744123

1）一个数据块在datanode上以文件形式存储在磁盘上，包括两个文件，一个是数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。

2）DataNode启动后向namenode注册，通过后，周期性（1小时）的向namenode上报所有的块信息。

3）心跳是每3秒一次，心跳返回结果带有namenode给该datanode的命令如复制块数据到另一台机器，或删除某个数据块。如果超过10分钟没有收到某个datanode的心跳，则认为该节点不可用。

4）集群运行中可以安全加入和退出一些机器（在不关闭集群的情况下服役和退役服务器）

6.2 数据完整性

1）当DataNode读取block的时候，它会计算checksum

2）如果计算后的checksum，与block创建时值不一样，说明block已经损坏。

3）client读取其他DataNode上的block。

4）datanode在其文件创建后周期验证checksum

1560170775293

6.3 掉线时限参数设置

datanode进程死亡或者网络故障造成datanode无法与namenode通信，namenode不会立即把该节点判定为死亡，要经过一段时间，这段时间暂称作超时时长。HDFS默认的超时时长为10分钟+30秒。如果定义超时时间为timeout，则超时时长的计算公式为：

​ timeout = 2 dfs.namenode.heartbeat.recheck-interval + 10 dfs.heartbeat.interval。

​ 而默认的dfs.namenode.heartbeat.recheck-interval 大小为5分钟，dfs.heartbeat.interval默认为3秒。

​ 需要注意的是hdfs-site.xml 配置文件中的heartbeat.recheck.interval的单位为毫秒，dfs.heartbeat.interval的单位为秒。

<property>
    <name>dfs.namenode.heartbeat.recheck-interval</name>
    <value>300000</value>
</property>
<property>
    <name> dfs.heartbeat.interval </name>
    <value>3</value>
</property>

6.4 DataNode的目录结构

和namenode不同的是，datanode的存储目录是初始阶段自动创建的，不需要额外格式化。

1）在/opt/module/hadoop-2.7.2/data/tmp/dfs/data/current这个目录下查看版本号

[kingge@hadoop102 current]$ cat VERSION

storageID=DS-1b998a1d-71a3-43d5-82dc-c0ff3294921b

clusterID=CID-1f2bf8d1-5ad2-4202-af1c-6713ab381175

cTime=0

datanodeUuid=970b2daf-63b8-4e17-a514-d81741392165

storageType=DATA_NODE

layoutVersion=-56

2）具体解释

​ （1）storageID：存储id号

​ （2）clusterID集群id，全局唯一

​ （3）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

​ （4）datanodeUuid：datanode的唯一识别码

​ （5）storageType：存储类型

​ （6）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

3）在/opt/module/hadoop-2.7.2/data/tmp/dfs/data/current/BP-97847618-192.168.10.102-1493726072779/current这个目录下查看该数据块的版本号

[kingge@hadoop102 current]$ cat VERSION

#Mon May 08 16:30:19 CST 2017

namespaceID=1933630176

cTime=0

blockpoolID=BP-97847618-192.168.10.102-1493726072779

layoutVersion=-56

4）具体解释

（1）namespaceID：是datanode首次访问namenode的时候从namenode处获取的storageID对每个datanode来说是唯一的（但对于单个datanode中所有存储目录来说则是相同的），namenode可用这个属性来区分不同datanode。

（2）cTime属性标记了datanode存储系统的创建时间，对于刚刚格式化的存储系统，这个属性为0；但是在文件系统升级之后，该值会更新到新的时间戳。

（3）blockpoolID：一个block pool id标识一个block pool，并且是跨集群的全局唯一。当一个新的Namespace被创建的时候(format过程的一部分)会创建并持久化一个唯一ID。在创建过程构建全局唯一的BlockPoolID比人为的配置更可靠一些。NN将BlockPoolID持久化到磁盘中，在后续的启动过程中，会再次load并使用。

（4）layoutVersion是一个负整数。通常只有HDFS增加新特性时才会更新这个版本号。

6.5 服役新数据节点

0）需求：

随着公司业务的增长，数据量越来越大，原有的数据节点的容量已经不能满足存储数据的需求，需要在原有集群基础上动态添加新的数据节点。

1）环境准备

​ （1）克隆一台虚拟机

​ （2）修改ip地址和主机名称

​ （3）修改xcall和xsync文件，增加新`增节点的同步ssh

​ （4）删除原来HDFS文件系统留存的文件

​ /opt/module/hadoop-2.7.2/data 和 /opt/module/hadoop-2.7.2/log目录

2）服役新节点具体步骤（下面的操作建议在namenode所在节点进行操作）

​ （1）在namenode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建dfs.hosts文件

[kingge@hadoop105 hadoop]$ pwd

/opt/module/hadoop-2.7.2/etc/hadoop

[kingge@hadoop105 hadoop]$ touch dfs.hosts （名字任意）

[kingge@hadoop105 hadoop]$ vi dfs.hosts

添加如下主机名称（包含新服役的节点）

hadoop102

hadoop103

hadoop104

hadoop105

​ （2）在namenode的hdfs-site.xml配置文件中增加dfs.hosts属性

<property>
<name>dfs.hosts</name>
      <value>/opt/module/hadoop-2.7.2/etc/hadoop/dfs.hosts</value>
</property>

​ （3）刷新namenode

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -refreshNodes

Refresh nodes successful

​ （4）更新resourcemanager节点

[kingge@hadoop102 hadoop-2.7.2]$ yarn rmadmin -refreshNodes

17/06/24 14:17:11 INFO client.RMProxy: Connecting to ResourceManager at hadoop103/192.168.1.103:8033

操作完后，打开**hdfs文件系统，发现已经服役了一个新的data**节点

1560171043334

​ （5）在namenode的slaves文件中增加新主机名称

​ 增加105 不需要分发

hadoop102

hadoop103

hadoop104

hadoop105

​ （6）单独命令启动新的数据节点和节点管理器

[kingge@hadoop105 hadoop-2.7.2]$ sbin/hadoop-daemon.sh start datanode

starting datanode, logging to /opt/module/hadoop-2.7.2/logs/hadoop-kingge-datanode-hadoop105.out

[kingge@hadoop105 hadoop-2.7.2]$ sbin/yarn-daemon.sh start nodemanager

starting nodemanager, logging to /opt/module/hadoop-2.7.2/logs/yarn-kingge-nodemanager-hadoop105.out

​ （7）在web浏览器上检查是否ok

3）如果数据不均衡，可以用命令实现集群的再平衡

​ [kingge@hadoop102 sbin]$ ./start-balancer.sh

starting balancer, logging to /opt/module/hadoop-2.7.2/logs/hadoop-kingge-balancer-hadoop102.out

Time Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved

6.6 退役旧数据节点

1）在namenode的/opt/module/hadoop-2.7.2/etc/hadoop目录下创建dfs.hosts.exclude文件

​ [kingge@hadoop102 hadoop]$ pwd

/opt/module/hadoop-2.7.2/etc/hadoop

[kingge@hadoop102 hadoop]$ touch dfs.hosts.exclude

[kingge@hadoop102 hadoop]$ vi dfs.hosts.exclude

添加如下主机名称（要退役的节点）

hadoop105

2）在namenode的hdfs-site.xml配置文件中增加dfs.hosts.exclude属性

<property>
<name>dfs.hosts.exclude</name>
      <value>/opt/module/hadoop-2.7.2/etc/hadoop/dfs.hosts.exclude</value>
</property>

3）刷新namenode、刷新resourcemanager

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -refreshNodes

Refresh nodes successful

[kingge@hadoop102 hadoop-2.7.2]$ yarn rmadmin -refreshNodes

17/06/24 14:55:56 INFO client.RMProxy: Connecting to ResourceManager at hadoop103/192.168.1.103:8033

4）检查web浏览器，退役节点的状态为decommission in progress（退役中），说明数据节点正在复制块到其他节点。

1560171084624

5）等待退役节点状态为decommissioned（所有块已经复制完成），停止该节点及节点资源管理器。注意：如果副本数是3，服役的节点小于等于3，是不能退役成功的，需要修改副本数后才能退役。·

1560171100904

[kingge@hadoop105 hadoop-2.7.2]$ sbin/hadoop-daemon.sh stop datanode

stopping datanode

[kingge@hadoop105 hadoop-2.7.2]$ sbin/yarn-daemon.sh stop nodemanager

stopping nodemanager

6）从include文件中删除退役节点，再运行刷新节点的命令

​ （1）从namenode的dfs.hosts文件中删除退役节点hadoop105

hadoop102

hadoop103

hadoop104

​ （2）刷新namenode，刷新resourcemanager

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -refreshNodes

Refresh nodes successful

[kingge@hadoop102 hadoop-2.7.2]$ yarn rmadmin -refreshNodes

17/06/24 14:55:56 INFO client.RMProxy: Connecting to ResourceManager at hadoop103/192.168.1.103:8033

7）从namenode的slave文件中删除退役节点hadoop105

hadoop102

hadoop103

hadoop104

8）如果数据不均衡，可以用命令实现集群的再平衡

[kingge@hadoop102 hadoop-2.7.2]$ sbin/start-balancer.sh

starting balancer, logging to /opt/module/hadoop-2.7.2/logs/hadoop-kingge-balancer-hadoop102.out

Time Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved

6.7 Datanode多目录配置

1）datanode也可以配置成多个目录，每个目录存储的数据不一样，即是上传一个文本，那么文本存储在data，但是data2什么都没有（跟namenode多目录区别）。即：数据不是副本。

2）具体配置如下：

​ hdfs-site.xml

<property>
        <name>dfs.datanode.data.dir</name>
        <value>file:///${hadoop.tmp.dir}/dfs/data1,file:///${hadoop.tmp.dir}/dfs/data2</value>
</property>

七 HDFS其他功能

7.1 集群间数据拷贝

1）scp实现两个远程主机之间的文件复制

​ scp -r hello.txt root@hadoop103:/user/kingge/hello.txt // 推 push

​ scp -r root@hadoop103:/user/kingge/hello.txt hello.txt // 拉 pull

​ scp -r root@hadoop103:/user/kingge/hello.txt root@hadoop104:/user/kingge //是通过本地主机中转实现两个远程主机的文件复制；如果在两个远程主机之间ssh没有配置的情况下可以使用该方式。

2）采用discp命令实现两个hadoop集群之间的递归数据复制

[kingge@hadoop102 hadoop-2.7.2]$ bin/hadoop distcp hdfs://haoop102:9000/user/kingge/hello.txt hdfs://hadoop103:9000/user/kingge/hello.txt

7.2 Hadoop存档

1）理论概述

每个文件均按块存储，每个块的元数据存储在namenode的内存中，因此hadoop存储小文件会非常低效。因为大量的小文件会耗尽namenode中的大部分内存。但注意，存储小文件所需要的磁盘容量和存储这些文件原始内容所需要的磁盘空间相比也不会增多。例如，一个1MB的文件以大小为128MB的块存储，使用的是1MB的磁盘空间，而不是128MB。

Hadoop存档文件或HAR文件，是一个更高效的文件存档工具，它将文件存入HDFS块，在减少namenode内存使用的同时，允许对文件进行透明的访问。具体说来，Hadoop存档文件可以用作MapReduce的输入。

2）案例实操

（1）需要启动yarn进程

​ [kingge@hadoop102 hadoop-2.7.2]$ start-yarn.sh

（2）归档文件

​ 归档成一个叫做xxx.har的文件夹，该文件夹下有相应的数据文件。Xx.har目录是一个整体，该目录看成是一个归档文件即可。

[kingge@hadoop102 hadoop-2.7.2]$ bin/hadoop archive -archiveName myhar.har -p /user/kingge /user/my

（3）查看归档

​ [kingge@hadoop102 hadoop-2.7.2]$ hadoop fs -lsr /user/my/myhar.har

[kingge@hadoop102 hadoop-2.7.2]$ hadoop fs -lsr har:///myhar.har

（4）解归档文件

[kingge@hadoop102 hadoop-2.7.2]$ hadoop fs -cp har:/// user/my/myhar.har /* /user/kingge

7.3 快照管理

快照相当于对目录做一个备份。并不会立即复制所有文件，而是指向同一个文件。当写入发生时，才会产生新文件。

1）基本语法

​ （1）hdfs dfsadmin -allowSnapshot 路径 （功能描述：开启指定目录的快照功能）

​ （2）hdfs dfsadmin -disallowSnapshot 路径 （功能描述：禁用指定目录的快照功能，默认是禁用）

​ （3）hdfs dfs -createSnapshot 路径 （功能描述：对目录创建快照）

​ （4）hdfs dfs -createSnapshot 路径 名称 （功能描述：指定名称创建快照）

​ （5）hdfs dfs -renameSnapshot 路径 旧名称 新名称 （功能描述：重命名快照）

​ （6）hdfs lsSnapshottableDir （功能描述：列出当前用户所有可快照目录）

​ （7）hdfs snapshotDiff 路径1 路径2 （功能描述：比较两个快照目录的不同之处）

​ （8）hdfs dfs -deleteSnapshot （功能描述：删除快照）

2）案例实操

​ （1）开启/禁用指定目录的快照功能

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -allowSnapshot /user/kingge/data

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfsadmin -disallowSnapshot /user/kingge/data

​ （2）对目录创建快照

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -createSnapshot /user/kingge/data

通过web访问hdfs://hadoop102:9000/user/kingge/data/.snapshot/s…..// 快照和源文件使用相同数据块

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -lsr /user/kingge/data/.snapshot/

​ （3）指定名称创建快照

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -createSnapshot /user/kingge/data miao170508

​ （4）重命名快照

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -renameSnapshot /user/kingge/data/ miao170508 kingge170508

​ （5）列出当前用户所有可快照目录

[kingge@hadoop102 hadoop-2.7.2]$ hdfs lsSnapshottableDir

​ （6）比较两个快照目录的不同之处

[kingge@hadoop102 hadoop-2.7.2]$ hdfs snapshotDiff /user/kingge/data/ . .snapshot/kingge170508

​ （7）恢复快照

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -cp /user/kingge/input/.snapshot/s20170708-134303.027 /user

7.4 回收站

1）默认回收站

默认值fs.trash.interval=0，0表示禁用回收站，可以设置删除文件的存活时间。

默认值fs.trash.checkpoint.interval=0，检查回收站的间隔时间。

要求fs.trash.checkpoint.interval<=fs.trash.interval。

1560171183235

2）启用回收站

修改core-site.xml，配置垃圾回收时间为1分钟。

<property>
    <name>fs.trash.interval</name>
    <value>1</value>
</property>

3）查看回收站

回收站在集群中的；路径：/user/kingge/.Trash/….

4）修改访问垃圾回收站用户名称(如果不修改为想要查看该回收站的用户的名称，那么该用户试图进入回收站时会提示权限问题)

​ 进入垃圾回收站用户名称，默认是dr.who，修改为kingge用户

​ [core-site.xml]

<property>
  <name>hadoop.http.staticuser.user</name>
  <value>kingge</value>
</property>

5）通过程序删除的文件不会经过回收站，需要调用moveToTrash()才进入回收站

Trash trash = New Trash(conf);

trash.moveToTrash(path);

6）恢复回收站数据

[kingge@hadoop102 hadoop-2.7.2]$ hadoop fs -mv /user/kingge/.Trash/Current/user/kingge/input /user/kingge/input

7）清空回收站（他并不是真正删除文件，而是生成一个当前时间戳的文件夹然后把回收站里面的文件都放到这个文件夹里面）

[kingge@hadoop102 hadoop-2.7.2]$ hdfs dfs -expunge

如果你感觉文章对你又些许感悟，你可以支持我！！
-------------本文结束感谢您的阅读-------------
分享到： 收藏夹 复制网址 邮件 微信 QQ空间 腾讯微薄 豆瓣 一键分享 更多