day01 HDFS
day01 HDFS
- 第一章 HDFS概述
- 第二章 HDFS的shell操作
- 第三章 HDFS客户端操作
- 第四章 HDFS的数据流(读和写)
- 第五章 NameNode和SecondaryNameNode
- 第六章 DataNode
- 第七章 HDFS 2.x新特性
- 第八章 HDFS HA
第一章 HDFS概述
1.1 HDFS产出的背景及定义
1.1.1 HDFS 产生背景
随着数据量越来越大,在一个操作系统存不下所有的数据,那么就分配到更多的操作系统管理的磁盘中,但是不方便管理和维护,迫切需要一种系统来管理多台机器上的文件,这就是分布式文件管理系统.HDFS只是分布式文件管理系统中的一种.
1.1.2 HDFS 定义
HDFS是一个文件系统, 用于存储文件, 通过目录树来定位文件; 其次它是分布式的,由很多服务器联合起来实现其功能,集群中的服务器有各自的角色.
HDFS的使用场景: 适合一次写入,多次读出的场景,且不支持文件的修改,适合用来做数据分析. 并不适合用来做网盘应用.
1.2 HDFS优缺点
1.2.1 优点
1.高容错性
2.适合处理大数据
3.可构建在廉价机器上
1.2.3 缺点
1.不适合低延时数据访问,比如毫秒级的存储数据,无法做到.
2.无法高效的对大量小文件进行存储
3.不支持并发写入,文件随机修改,仅支持数据追加
1.3 HDFS 组成架构
- NameNode: Master,HDFS的主管,管理者
(1) 管理HDFS的名称空间
(2) 配置副本策略
(3) 管理数据块的映射信息
(4) 处理客户端读写请求
- DataNode: Slave.NameNode下达命令,DataNode执行实际操作
(1) 存储实际的数据块
(2) 执行数据块的读写操作
- client: 客户端
(1) 切分文件,文件上传到HDFS的时候,是由client进行切分的
(2) 与NameNode进行交互,获取文件的位置信息
(3) 与DataNode进行交互,读取或写入数据
(4) Client通过一些命令来管理HDFS,比如HDFS格式化
(5) Client 可以通过一些命令访问HDFS ,比如HDFS增删改查操作.
- SecondNameNode: 并非NameNode的热备, 当NameNode挂掉的时候,它并不能马上替换NameNode并提供服务
(1) 辅助NameNode,分担其工作量,比如定期合并Fsimage和Edits ,并推送给NameNode
(2) 在紧急情况下, 可辅助恢复NameNode
1.4 HDFS 文件块大小
HDFS中的文件在物理上是分块存储的. 文件以块的形式分布式的存储在HDFS中.
HDFS块的大小可以通过配置参数(dfs.blocksize) 来规定,默认是128M
块的大小不能设置的太小,也不能设置的太大??
文件系统有寻址时间和传输时间 ,一般地, 寻址时间为传输时间的1% 时,则为最佳状态.
(1) HDFS的块设置的太小.会增加寻址时间.即程序一直在寻找块的位置
(2) HDFS的块设置的太大,从磁盘传输数据的时间会明显大于寻找定位这个块的时间.
HDFS块的大小设置主要取决于磁盘传输速度.
几个问题:
- HDFS系统文件引入分块存储
在HDFS系统中,为了便于文件的管理和备份,引入分块概念(block)。这里的块是HDFS存储系统当中的最小单位,HDFS默认定义一个块的大小为128MB。当有文件上传到HDFS上时,若文件大小大于设置的块大小,则该文件会被切分存储为多个块,多个块可以存放在不同的DataNode上,整个过程中 HDFS系统会保证一个块存储在一个datanode上 。但值得注意的是 如果某文件大小没有到达128MB,该文件并不会占据整个块空间 。
HDFS中的NameNode会记录在上述文件分块中文件的各个块都存放在哪个dataNode上,这些信息一般也称为元信息(MetaInfo) 。元信息的存储位置由dfs.name.dir指定。
- 使用存储块的好处
(1) 分布式存储
(2) 冗余备份
(3) 并行读取
- 为什么64MB或者128MB或256MB是最优的选择?
文件系统有寻址时间和传输时间 ,一般地, 寻址时间为传输时间的1% 时,则为最佳状态.
(1) HDFS的块设置的太小.会增加寻址时间.即程序一直在寻找块的位置
(2) HDFS的块设置的太大,从磁盘传输数据的时间会明显大于寻找定位这个块的时间.
- 为什么不能远大于64MB或者128MB或256MB?
(1)Map崩溃问题:
系统需要重新启动,启动过程需要重新加载数据,数据块越大,数据加载时间越长,系统恢复过程越长。
(2)监管时间问题:
主节点监管其他节点的情况,每个节点会周期性的把完成的工作和状态的更新报告回来。如果一个节点保持沉默超过一个预设的时间间隔,主节点记录下这个节点状态为死亡,
并把分配给这个节点的数据发到别的节点。对于这个“预设的时间间隔”,这是从数据块的角度大概估算的。假如是对于64MB的数据块,我可以假设你10分钟之内无论如何也能解决了吧,
超过10分钟也没反应,那就是死了。可对于640MB或是1G以上的数据,我应该要估算个多长的时间呢?估算的时间短了,那就误判死亡了,更坏的情况是所有节点都会被判死亡。
估算的时间长了,那等待的时间就过长了。所以对于过大的数据块,这个“预设的时间间隔”不好估算。
(3)Map任务上:
因为MapReducer中一般一个map处理一个块上的数据,如果块很大,任务数会很少(少于集群中的节点个数)这样执行效率会明显降低。
- 为什么分片大小需要与HDFS数据块(分块)大小一致
hadoop将mapReduce的输入数据划分为等长的小数据块,称为输入分片或者分片,hadoop为每个分片构建一个map任务。
hadoop在存储有输入数据(HDFS中的数据)的节点上运行map任务,可以获得高性能,这就是所谓的数据本地化。所以最佳分片的大小应该与HDFS上的块大小一样,因为如果分片跨越2个数据块,对于任何一个HDFS节点(基本不肯能同时存储这2个数据块),分片中的另外一块数据就需要通过网络传输到map任务节点,与使用本地数据运行map任务相比,效率则更低!
第二章 HDFS的shell操作
1. -ls : 显示目录信息
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -ls /
2. -mkdir : 在HDFS上创建目录
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -mkdir -p /sanguo/shuguo
3. -moveFromLocal: 从本地剪切粘贴到HDFS
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -moveFromLocal ./test.txt /sanguo/shuguo
4. -appendToFile: 追加一个文件到已经存在的文件末尾
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -appendTofile liubei.txt /sanguo/kongming.txt
5. -cat: 显示文件内容
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -cat /sanguo/shuguo/kongming.txt
6. -chgrp 、-chmod、-chown:Linux文件系统中的用法一样,修改文件所属权限
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -chown yanlzh:yanlzh /sanguo/shuguo/kongming.txt
7. -copyFromLocal: 从本地文件系统的拷贝文件到HDFS路径中去
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -copyFromLocal ./test.txt /test/
8. -copyToLocal: 从HDFS拷贝到本地
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -copyToLocal /sanguo/shuguo/kongming.txt /home/yanlzh/
9. -cp : 赋值
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -cp /sanguo/shuguo/kongming.txt /zhuge.txt
11. -mv : 移动文件
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -mv /zhuge.txt /sanguo/shuguo/
12. -get: 等同于copyToLocal
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -get /sanguo/shuguo/kongming.txt /home/yanlzh/
13. -getmerge: 合并下载多个文件.比如HDFS的目录 /user/yanlzh/test下有多个文件:log.1, log.2,log.3,...
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -getmerge /user/yanlzh/test/* /home/yanlzh/
14. -put:等同于copyFromLocal
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -put /home/yanlzh/a.txt /
15. -tail:显示一个文件的末尾
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -tail /sangguo/shuguo/kongming.txt
16. -rm:删除文件或文件夹
[aaa@qq.com hadoop-2.7.2]$ hadoop fs - rm /sanguo/shuguo/kongming.txt
17. -rmdir:删除空目录
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -rmdir /test
18. -du统计文件夹的大小信息
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -du -s -h /user/yanlzh/test
19. -setrep:设置HDFS中文件的副本数量
[aaa@qq.com hadoop-2.7.2]$ hadoop fs -setrep 10 /sanguo/shuguo/kongming.txt
第三章 HDFS客户端操作
3.1 HDFS的API操作
两个对象
Configuration(org.apache.hadoop.conf.Configuration)
FileSystem(org.apache.hadoop.fs.FileSystem)
3.1.1 HDFS文件下载
@Test
public void testCopyFromLocalFile() throws Exception {
// 1. 获取文件系统对象FileSystem
Configuration configuration = new Configuration();
configuration.set("dfs.replication","2");
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node01:9000"), configuration, "yanlzh");
// 2. 上传文件
fileSystem.copyFromLocalFile(new Path("E:/test.txt"),new Path("/"));
fileSystem.close();
}
参数生效的优先级
(1)客户端代码中设置的值 >(2)ClassPath下的用户自定义配置文件 >(3)然后是服务器的默认配置
3.1.2 HDFS文件下载
@Test
public void testCopyToLocalFile() throws Exception {
Configuration configuration = new Configuration();
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node01:9000"), configuration, "yanlzh");
// boolean delSrc 指是否将原文件删除
// Path src 指要下载的文件路径
// Path dst 指将文件下载到的路径
// boolean useRawLocalFileSystem 是否开启文件校验
fileSystem.copyToLocalFile(false,new Path("/test.txt"),new Path("E:/test1.txt"),true);
fileSystem.close();
}
3.1.3 HDFS文件和文件夹判断
@Test
public void testListStatus() throws Exception {
Configuration configuration = new Configuration();
FileSystem fileSystem = FileSystem.get(new URI("hdfs://node01:9000"), configuration, "yanlzh");
FileStatus[] fileStatuses = fileSystem.listStatus(new Path("/"));
for (FileStatus fileStatus : fileStatuses) {
if (fileStatus.isFile()) {
System.out.println("f:" + fileStatus.getPath().getName());
} else {
System.out.println("d:" + fileStatus.getPath().getName());
}
}
fileSystem.close();
}
3.2 HDFS的IO流操作(自定义)
3.2.1 HDFS文件上传
@Test
public void putFileToHDFS() throws IOException, InterruptedException, URISyntaxException {
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://hadoop102:9000"), configuration, "atguigu");
// 2 创建输入流
FileInputStream fis = new FileInputStream(new File("e:/banhua.txt"));
// 3 获取输出流
FSDataOutputStream fos = fs.create(new Path("/banhua.txt"));
// 4 流对拷
IOUtils.copyBytes(fis, fos, configuration);
// 5 关闭资源
IOUtils.closeStream(fos);
IOUtils.closeStream(fis);
fs.close();
}
3.2.2 HDFS文件下载
// 文件下载
@Test
public void getFileFromHDFS() throws IOException, InterruptedException, URISyntaxException{
// 1 获取文件系统
Configuration configuration = new Configuration();
FileSystem fs = FileSystem.get(new URI("hdfs://hadoop102:9000"), configuration, "atguigu");
// 2 获取输入流
FSDataInputStream fis = fs.open(new Path("/banhua.txt"));
// 3 获取输出流
FileOutputStream fos = new FileOutputStream(new File("e:/banhua.txt"));
// 4 流的对拷
IOUtils.copyBytes(fis, fos, configuration);
// 5 关闭资源
IOUtils.closeStream(fos);
IOUtils.closeStream(fis);
fs.close();
}
第四章 HDFS的数据流(读和写)
4.1 HDFS写数据流程(上传)
4.1.1 上传流程
图中NameNode向客户端返回的DataNode的数量由副本数决定;
返回哪几个DataNode 由后续的网络拓扑和机架感知决定
流程如下
1)客户端通过Distributed FileSystem模块向NameNode请求上传文件,NameNode检查目标文件是否已存在,父目录是否存在。
2)NameNode返回是否可以上传。
3)客户端请求第一个 Block上传到哪几个DataNode服务器上。
4)NameNode返回3个DataNode节点,分别为dn1、dn2、dn3。
5)客户端通过FSDataOutputStream模块请求dn1上传数据,dn1收到请求会继续调用dn2,然后dn2调用dn3,将这个通信管道建立完成。
6)dn1、dn2、dn3逐级应答客户端。
7)客户端开始往dn1上传第一个Block(先从磁盘读取数据放到一个本地内存缓存),以Packet为单位,dn1收到一个Packet就会传给dn2,dn2传给dn3;dn1每传一个packet会放入一个应答队列等待应答。
8)当一个Block传输完成之后,客户端再次请求NameNode上传第二个Block的服务器。(重复执行3-7步)。
4.1.2 网络拓扑-节点距离计算(第一个DataNode的选择)
在HDFS写数据的过程中,NameNode会选择距离待上传数据最近距离的DataNode接收数据。
那么这个最近距离怎么计算呢?
数线段个数
4.1.3 机架感知(副本DataNode的选择)
第一个副本在Client所处的节点上(节点距离最近,为0),如果客户端在集群外,则随机选择一个
第二个副本和第一个副本位于相同机架,随机节点
第三个副本位于不同机架,随机节点
4.2 HDFS读数据流程(下载)
注: 客户端只会和一个DataNode建立通道,其他的DataNode作为备胎,当第一个DataNode不通时,再去和后面的建立
流程如下
1)客户端通过Distributed FileSystem向NameNode请求下载文件,NameNode通过查询元数据,找到文件块所在的DataNode地址。
2)挑选一台DataNode(就近原则,然后随机)服务器,请求读取数据。
3)DataNode开始传输数据给客户端(从磁盘里面读取数据输入流,以Packet为单位来做校验)。
4)客户端以Packet为单位接收,先在本地缓存,然后写入目标文件。
第五章 NameNode和SecondaryNameNode
5.1 NN和2NN工作机制
思考:
1.NameNode的元数据该存放在哪里才能保证又高效又安全?
2.SecondaryNameNode有什么用?
面对第一个问题(解决方案):
(1) 元数据存放在内存中>> 不安全 >> 在磁盘中备份元数据 (FsImage)
(2) 使用FsImage面临的新问题: 在内存中更新元数据时:
a.如果同时更新磁盘中的FsImage , 效率太低
b.如果不更新磁盘中的FsImage, 数据不一致
(3) 引入Edits文件: 对Edits文件只进行追加(效率很高),每当元数据有更新或者添加元数据时,修改内存中的元数据,并且将更新的内容追加到Edits中, 一旦NameNode节点断电,可以通过FsImage和Edits的合并,重新得到元数据.
(4) 如果长时间添加数据到Edits 文件中,会导致该文件过大, 那么在NameNode故障时,重新启动后,合并FsImage和Edits需要很长的时间.
(5) 于是,需要定期的进行FsImage 和 Edits文件的合并,如果这个操作有NameNode来完成,又会效率过低. 古 ,引入一个新的节点SecondaryNameNode,专门用于FsImage和Edits文件的合并
5.1.1 关于NameNode
(1)第一次启动NameNode格式化后,创建Fsimage和Edits文件。如果不是第一次启动,直接加载编辑日志和镜像文件到内存。
(2)客户端对元数据进行增删改的请求。
(3)NameNode记录操作日志,更新滚动日志。
(4)NameNode在内存中对元数据进行增删改。
5.1.2 关于SecondaryNameNode
(1)Secondary NameNode询问NameNode是否需要CheckPoint。直接带回NameNode是否检查结果。
(2)Secondary NameNode请求执行CheckPoint。
(3)NameNode滚动正在写的Edits日志。
(4)将滚动前的编辑日志和镜像文件拷贝到Secondary NameNode。
(5)Secondary NameNode加载编辑日志和镜像文件到内存,并合并。
(6)生成新的镜像文件fsimage.chkpoint。
(7)拷贝fsimage.chkpoint到NameNode。
(8)NameNode将fsimage.chkpoint重新命名成fsimage。
5.1.3 NN和2NN总结
Fsimage:NameNode内存中元数据序列化后形成的文件。
Edits:记录客户端更新元数据信息的每一步操作(可通过Edits运算出元数据)。
NameNode启动时,先滚动Edits并生成一个空的edits.inprogress,然后加载Edits和Fsimage到内存中,此时NameNode内存就持有最新的元数据信息。Client开始对NameNode发送元数据的增删改的请求,这些请求的操作首先会被记录到edits.inprogress中(查询元数据的操作不会被记录在Edits中,因为查询操作不会更改元数据信息),如果此时NameNode挂掉,重启后会从Edits中读取元数据的信息。然后,NameNode会在内存中执行元数据的增删改的操作。
由于Edits中记录的操作会越来越多,Edits文件会越来越大,导致NameNode在启动加载Edits时会很慢,所以需要对Edits和Fsimage进行合并(所谓合并,就是将Edits和Fsimage加载到内存中,照着Edits中的操作一步步执行,最终形成新的Fsimage)。SecondaryNameNode的作用就是帮助NameNode进行Edits和Fsimage的合并工作。
SecondaryNameNode首先会询问NameNode是否需要CheckPoint(触发CheckPoint需要满足两个条件中的任意一个,定时时间到和Edits中数据写满了)。直接带回NameNode是否检查结果。SecondaryNameNode执行CheckPoint操作,首先会让NameNode滚动Edits并生成一个空的edits.inprogress,滚动Edits的目的是给Edits打个标记,以后所有新的操作都写入edits.inprogress,其他未合并的Edits和Fsimage会拷贝到SecondaryNameNode的本地,然后将拷贝的Edits和Fsimage加载到内存中进行合并,生成fsimage.chkpoint,然后将fsimage.chkpoint拷贝给NameNode,重命名为Fsimage后替换掉原来的Fsimage。NameNode在启动时就只需要加载之前未合并的Edits和Fsimage即可,因为合并过的Edits中的元数据信息已经被记录在Fsimage中。
5.2 Fsimage和Edits解析
概念
5.3 CheckPoint时间设置
[hdfs-default.xml]
(1) 通常情况下,SecondaryNameNode每隔一小时执行一次。
<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.4 NameNode故障处理
NameNode故障后,可以采用以下两种方式恢复数据:
5.4.1 方法一(将SecondaryNameNode中数据拷贝到NameNode存储数据的目录)
- kill -9 NameNode进程
- 删除NameNode存储的数据(/home/yanlz/app/hadoop-2.7.2/data/tmp/dfs/name)
[aaa@qq.com hadoop-2.7.2]$ rm -rf /home/yanlz/hadoopdata/name/*
- 拷贝SecondaryNameNode中的数据到原NameNode存储数据目录
[aaa@qq.com hadoop-2.7.2]$ scp - r aaa@qq.com:/home/yanlzh/hadoopdata/dfs/namesecondary/* /home/yanlz/hadoopdata/name/
- 重新启动NameNode
[aaa@qq.com hadoop-2.7.2]$ sbin/hadoop-daemon.sh startnamenode
5.4.2 方法二(使用-importCheckpoint选项)
使用-importCheckpoint选项启动NameNode守护进程,
从而将SecondaryNameNode中数据拷贝到NameNode目录中。
- 修改hdfs-site.xml
- kill -9 NameNode进程
- 删除NameNode存储的数据
- 如果SecondaryNameNode不和NameNode在一个主机节点上,需要将SecondaryNameNode存储数据的目录拷贝到NameNode存储数据的平级目录,并删除in_use.lock文件
- 导入检查点数据(等待一会ctrl+c结束掉)
- 启动NameNode
5.5 集群安全模式
- NameNode启动
NameNode启动时,首先将镜像文件(FsImage)载入内存,并执行编辑日志(Edits)中的各项操作.一旦在内存中成功建立文件系统元数据的映像,则创建一个新的FsImage文件和一个空的编辑日志.此时,NameNode开始监听DataNode请求.这个过程期间,NameNode一直运行在安全模式, 即NameNode的文件系统对于客户端来说是只读的;
- DataNode启动
系统中数据块的位置并不是由NameNode维护的,而是以块列表的形式存储在DataNode中. 在系统的正常操作期间,NameNode会在内存中保留所有块位置的映射信息.在安全模式下,各个DataNode会向NameNode发送最新的块列表信息,NameNode了解到足够多的块位置信息后,即可高效运行文件系统;
- 安全模式退出判断
如果满足"最小副本条件" ,NameNode会在30 秒钟之后就退出安全模式.所谓的最小副本条件------整个文件系统的99.9%的块满足最小副本级别(默认值: dfs.replication.min = 1). 在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以NameNode不会进入安全模式.
第六章 DataNode
6.1 DataNode 工作机制
图解
1)一个数据块在DataNode上以文件形式存储在磁盘上,包括两个文件,一个是数据本身,一个是元数据包括数据块的长度,块数据的校验和,以及时间戳。
2)DataNode启动后向NameNode注册,通过后,周期性(1小时)的向NameNode上报所有的块信息。
3)心跳是每3秒一次,心跳返回结果带有NameNode给该DataNode的命令如复制块数据到另一台机器,或删除某个数据块。如果超过10分钟没有收到某个DataNode的心跳,则认为该节点不可用。
4)集群运行中可以安全加入和退出一些机器。
6.2 数据完整性
DataNode节点上的数据损坏了,却没有发现,很危险,那么如何解决呢?
如下是DataNode节点保证数据完整性的方法。
1)当DataNode读取Block的时候,它会计算CheckSum。
2)如果计算后的CheckSum,与Block创建时值不一样,说明Block已经损坏。
3)Client读取其他DataNode上的Block。
4)DataNode在其文件创建后周期验证CheckSum。
6.3 掉线时限参数设置
参数设置 hdfs-site.xml
<property>
<!--超时时间,单位毫秒-->
<name>dfs.namenode.heartbeat.recheck-interval</name>
<value>300000</value>
</property>
<property>
<!--心跳发送周期, 单位秒-->
<name>dfs.heartbeat.interval</name>
<value>3</value>
</property>
6.4 服役新数据节点
需求
随着公司业务的增长,数据量越来越大,原有的数据节点的容量已经不能满足存储数据的需求,需要在原有集群基础上动态添加新的数据节点。
- 环境准备
(1) 在node03主机上再克隆一台node04主机
(2) 修改IP地址和主机名称
(3) source一下配置文件
[aaa@qq.com hadoop-2.7.2]$ source /etc/profile
- 服役新节点具体步骤
(1) 直接启动DataNode,即可关联到集群
[aaa@qq.com hadoop-2.7.2]$ sbin/hadoop-daemon.sh start datanode
[aaa@qq.com hadoop-2.7.2]$ sbin/yarn-daemon.sh start nodemanager
6.5 退役旧数据节点
6.5.1 添加白名单
添加到白名单的主机节点,都允许访问NameNode,不在白名单的主机节点,都会被退出
配置白名单
- 在NameNode的/home/yanlzh/app/hadoop-2.7.2/etc/hadoop目录下创建 dfs.hosts 文件
[aaa@qq.com hadoop]$ touch dfs.hosts
[aaa@qq.com hadoop]$ vim dfs.hosts
添加如下主机名称(退役node04)
node01
node02
node03
- 在NameNode的hdfs-site.xml 配置文件中增加dfs.hosts属性
<property>
<name>dfs.hosts</name>
<value>/home/yanlzh/app/hadoop-2.7.2/etc/hadoop/dfs.hosts</value>
</property>
- 配置文件分发
[aaa@qq.com hadoop]$ xsync hdfs-site.xml
- 刷新NameNode
[aaa@qq.com hadoop-2.7.2]$ hdfs dfsadmin -refreshNodes
- 更新ResourceManager
[aaa@qq.com hadoop-2.7.2]$ yarn rmadmin -refreshNodes
6.5.2 黑名单退役
在黑名单上面的主机都会被强制退出
配置黑名单
- 在NameNode的/home/yanlzh/app/hadoop-2.7.2/etc/hadoop目录下创建dfs.hosts.exclude文件
[aaa@qq.com hadoop]$ touch dfs.hosts.exclude
[aaa@qq.com hadoop]$ vim dfs.hosts.exclude
- 在NameNode的hdfs-site.xml配置文件中增加dfs.hosts.exclude属性
<property>
<name>dfs.hosts.exclude</name>
<value>/home/yanlzh/app/hadoop-2.7.2/etc/hadoop/dfs.hosts.exclude</value>
</property>
- 刷新NameNode、刷新ResourceManager
6.6 DataNode多目录配置
DataNode也可以配置成多个目录, 每个目录存储的数据不一样,即: 数据不是副本
具体配置如下(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 2.x新特性
第八章 HDFS HA
上一篇: EventBus原理与源码解析
下一篇: dubbo源码解析-简单原理