整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

第10章 管理Hadoop

hadoop 花牛 32℃ 0评论

10章

管理Hadoop

9章介绍了如何搭建Hadoop集群。本章将关注如何保障集群的平稳 运行。

10.1 HDFS

10.1.1永久性数据结构

对于管理员来说,深入了解namenode辅助namenodedatanode HDFS组件如何在磁盘上组织永久性数据非常重要。洞悉各文件的用法有助 于进行故障诊断和故障检出。

1. namenode的目录结构

namenode被格式化之后,将产生如下所示的目录结构:

${dfs.name.dir}/

1 current/

| VERSION

| edits

| fsimage

1 fstime

如第9章所示,dfsnamedir属性描述了一组目录,各个目录存储着镜像 内容。该机制使系统具备了一定的复原能力,特别是当其中一个目录是 NFS的一个挂载时(推荐配置)。

VERSION文件是一个Java属性文件,其中包含正在运行的HDFS的版本信 息。该文件一般包含以下内容:

#Tue Mar 10 19:21:36 GMT 2009 namespaceID=l34368441


cTime=0

storageType=NAME_NODE

layoutVersion=-18

属性layoutVersion是一个负整数,描述HDFS持久性数据结构(也称布

局)的版本,但是该版本号与Hadoop发布包的版本号无关。只要布局变 更,版本号便会递减(例如,版本号-18之后是-19),此时,HDFS也需要升 级。否则,磁盘仍然使用旧版本的布局,新版本的namenode(或datanode) 就无法正常工作。如何升级HDFS,请参见10.3.3节。

属性namespacelD是文件系统的唯一标识符,是在文件系统首次格式化时 设置的。任何datanode在注册到namenode之前都不知道namespacelD 值,因此namenode可以使用该属性鉴别新建的datanode

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

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

Namenode的存储目录中还包含和W/we等二进制文件。这些文件都使用HadoopWritable对象作为其序列化格式(参见4.3节对序列化的讨论)。只有深入学习namenode的工作机理,才能够理解这些文件的用途。

 

2. 文件系统映像和编辑日志

文件系统客户端执行写操作时(例如创建或移动文件),这些操作首先被记录到编辑日志中。namenode在内存中维护文件系统的元数据;当编辑日志被修改时,相关元数据信息也同步更新。内存中的元数据可支持客户端的读请求。

在每次执行写操作之后,且在向客户端发送成功代码之前,编辑日志都需要更新和同步。当namenode向多个目录写数据时,只有在所有写操作均执行完毕之后方可返回成功代码,以确保任何操作都不会因为机器故障而

丢失。

fsimage文件是文件系统元数据的一个永久性检查点。并非每一个写操作都 会更新该文件,因为fsimage是一个大型文件(甚至可髙达几个GB),如果频繁地执行写操作,会使系统运行极为缓慢。但这个特性根本不会降低系


统的恢复能力,因为如果namenode发生故障,可以先把fsimage文件载入到内存重构新近的元数据,再执行编辑日志中记录的各项操作。事实上,namenode在启动阶段正是这样做的(参见10.1.2节对安全模式的讨论)。

fsimage文件包含文件系统中的所有目录和文件inode的序列化信息。每个inode是一个文件或目录的元数据的内部描述方式。对于文 件来说,包含的信息有“复本级别replication level)、修改时间和访问时间、访问许可、块大小、组成一个文件的块等> 对于目录来说,包含的信息有修改时间、访问许可和配额元数据等信息。

数据块存储在datanode中,但fsimage文件并不描述datanode取而 代之的是,namenode将这种块映射关系放在内存中。当datanode 入集群时,namenodedatanode索取块列表以建立块映射关系, namenode还将定期征询datanode以确保它拥有最新的块映射。

如前所述,文件会无限增长。尽管这种情况对于namenode的运行没有影响,但由于需要恢复(非常长的)编辑日志中的各项操作,namenode的重启操作会比较慢。在这段时间内,将文件系统处于离线状态,会有违用户的期望。

解决方案是运行辅助namenode,‘为主namenode内存中的文件系统元数据 创建检査点。®创建检査点的步骤如下所示(参见图10-1)。

(1) 辅助namenode请求主namenode停止使用edits文件,暂时将新的 写操作记录到一个新文件中。

(2) 辅助namenode从丰namenode获取fsimageedits文件(采用 HTTP GET)。

(3)  辅助namenodefsimage文件载入内存,逐一执行edits文件中的 操作,创建新的fsimage文件。

(4) 辅助namenode将新的fsimage文件发送回主namenode(使用HTTP POST)。

(5)namenode用从辅助namenode接收的fsimagee文件替换旧的 fsimage文件,用步骤丨所产生的edits文件替换旧的edits文件。同时,还更新fstime文件来记录检査点执行的时间。

最终,主namenode拥有最新的fsimage文件和一个更小的edits文件(edits文件可能非空,因为在这个过程中主namenode还可能收到一些写请求)。 当namenode处在安全模式时,管理员也可调用hadoop dfsadmin – saveNamespace命令来创建检査点。

image.png 

 

10-1.创建检查点的过程

 

 

该过程清晰地解释了辅助namenode和主namenode拥有相近内存需求的原 因(因为辅助namenode也把/fsimage文件载入内存)。因此,在大型集群 中,辅助namenode需要运行在一台专用机器上。

创建检査点的触发条件受两个配置参数控制。通常情况下,辅助namenode 每隔一小时(由fs.checkpoint.period属性设置,以秒为单位)创建检查


点;此外,当编辑日志的大小达到64MB(由fs.checkpoint.size属性设置,以字节为单位)时,即使未到一小时也会创建检査点。系统每隔五分钟检查一次编辑日志的大小。

3.辅助namenode的目录结构

创建检査点的过程不仅为主namenode创建检査点数据,还使辅助namenode最终也有一份检查点数据(存储在previous.checkpoint子目录中)。这份数据可用作namenode元数据的(尽管并非最新)备份:

${fs.checkpoint.dir}/

I current/

| VERSION

I edits

I fsimage

1 fstime

1 previous.checkpoint/

h VERSION

| edits

I fsimage

1 fstime

辅助 namenode  previous.cheakpoint目录、辅助 namenode current目录

和主namenodecurrent貝录的布局相同。这种设计方案的好处是,在主 namenode发生故障时(假设没有及时备份,甚至在NFS上也没有),可以从 辅助namenode恢复数据。有两种实现方法。方法一是将相关存储目录复 制到新的namenode中;方法二是使用-importCheckpoint选项启动 namenode守护进程,从而将辅助namenode用作新的主namenode借助该 选项,当dfs.name.dir属性定义的目录中没有元数据时,辅助namenode 就从fs.checkpoint.dir目录载入最新的检查点数据,否则执行失败。因 此,无需担心该操作会覆盖现的元数据。

4. datanode的目录结构

namenode不同的是,datanode的存储目录是初始阶段自动创建的,不需 要额外格式化。datanode的关键文件和目录如下所示:

${dfs.data.dir}/current/VERSION /blk_<id_l>

/blk_<id_l>.meta /blk_<id_2>

/blk_<id_2>.meta /•••

/blk_<id_64>


/blk_<id_64>•meta /subdirO/

/subdirl/

/

/subdir63/

datanodeVERSION文件与namenodeVERSION文件非常相似,如下

所示:

#Tue Mar 10 21:32:31 GMT 2009 namespaceID=l34368441

storageID=DS-547717739-172.16.85.1-50010-1236720751627 cTime=0

storageType=DATA_NODE

layoutVersion=-18

namespacelD 属性、cTime 属性和 layoutVersion 属性的值与 namenode 中的值相同。实际上,namespacelDdatanode首次访问namenode的时 候从namenode处获取的storagelD对每个datanode来说是唯一的(但对 于单个datanode中所有存储目录来说则是相同的),namenode可用这个属性 来区分不同datanodestorageType表明该目录是datanode的存储目录。

datanodecurrent目录中的其他文件都有blk_前缀,包括两种文件类型: HDFS块文件(仅包含原始数据)和块的元数据文件(含.meta后缀)。块文件包 含所存储文件中一部分的原始数据;元数据文件包括头部(含版本和类型信 息)和该块各区段的一系列的校验和。

当目录中数据块的数量增加到一定规模时,datanode会创建一个子目录来 存放新的数据块及其元数据信息。如果当前目录已经存储了 64个(通过 dfs.datanode.numblocks属性设置)数据块时,就创建一个子目录。终极 目标是设计一棵高扇出的目录树,即使文件系统中的块数量非常多,目录 树的层数也不多。通过这种方式,datanode可以有效管理各个目录中的文 件,避免大多数操作系统遇到的管理难题,即很多(成千上万个)文件都放在 同一个目录之中。

如果dfs.data.dir属性指定了不同磁盘上的多个目录,那么数据块会以轮转roundrobin)的方式写到各个目录中。注意,同一个datanode上的每个磁盘上的块不会重复,不同datanode之间的块才可能重复。


10.1.2安全模式

 

namenode启动时,首先将映像文件(fsimage)载人内存,并执行编辑日志 (edits)中的各项操作。一且在内存中成功建立文件系统元数据的映像,则创 建一个新的fsimage文件(该操作不需要借助辅助namenode)和一个空的编辑 日志。此时,namenode开始监听RPCHTTP请求。但是此刻namenode 运行在安全模式,即namenode的文件系统对于客户端来说是只读的。

, 严格来说,在安全模式下,只有那些访问文件系统元数据的文件系

统操作是肯定成功执行的,例如显示目录列表等。对于读文件操作来说,只在集群中当前datenode上的可用时,才能够工作。但文件修改操作(包括写、删除或重命名)均会失败。

需要强调的是,系统中数据块的位置并不是由namenode维护的,而是以块列表的形式存储在datanode中。在系统的正常操作期间,namenode会在内 存中保留所有块位置的映射信息。在安全模式下,各个datanode会向 namenode发送最新的块列表信息,namenode 了解到足够多的块位置信息之 后,即可高效运行文件系统。如果namenode认为向其发送更新信息的datanode节点过少,则它会启动块复制进程,以将数据块复制到新的 datanode节点。然而,在大多数情况下上述操作都是不必要的(因为实际上 namenode只需继续等待更多datanode发送更新信息即可),并浪费了集群的资源。实际上,在安全模式下namenode并不向datanode发出任何块复制或块删除的指令。

如果满足“最小复本条件minimal replication condition), namenode 会在 3〇秒钟之后就退出安全模式。所谓的最小复本条件指的是在整个文件系统 中有99.9%的块满足最小'复本级别(默认值是1,由dfs. replication.min 属性设置,参见表10-1)。

在启动一个刚刚格式化的HDFS集群时,因为系统中还没有任何块,所以 namenode不会进入安全模式。

进入和离开安全模式

为了查看namenode是否处于安全模式,可以像下面这样使用dfsadmin命令:

% hadoop dfsadmin -safemode get

Safe mode is ON

HDFS的网页界面也能够显示namenode是否处于安全模式。


1C-1安全模式的属性

属性名称 类型 默认值 说明

dfs.replication.min int 1 成功执行写操作所需要创建的

最少复本数目(也称为最小复本 级别)

dfs. safemode .threshold. pct float 0.999 namenode 退出安全模式之

前,系统中满足最小复本级别 (由 dfs.replication.min 义)的块的比例。将这项值设为 〇或更小会令namenode无法启 #动安全模式;设为髙于1则永

远不会退出安全模式

dfs. safemode.extension int 30 000      在满足最小复本条件(由dfs.safemode.threshold.pct 定义)之后,namenode还需要处 于安全模式的时间(以毫秒为单 位)。对于小型集群(几十个节 )来说,这项值可以设为0

有时用户会期望在执行某条命令之前namenode先退出安全模式,特别是在 脚本中。使用wait选项能够达到这个目的:

hadoop dfsadmin -safemode wait

# command to read or write a file

管理员随时可以让namenode进人或离开安全模式.这项功能在维护和升级 集群时非常关键,因为需要确保数据在指定时段内是只读的。使用以下指令 进入安全模式:

% hadoop dfsadmin -safemode enter

Safe mode is ON

前面提到过,namenode在启动阶段会处于安全模式。在此期间也可使用这 条命令,从而确保namenode在启动完毕之后不离开安全模式。另一种使 namenode永远处于安全模式的方法是将属性dfs.safemode.threshold.pct

的值设为大于>1


运行以下指令即可离开安全模式:

% hadoop dfsadmin -safemode leave

Safe mode is OFF

10.1.3 曰志审计

HDFS的日志能够记录所有文件系统访问请求,有些组织需要这项特性来进 行审计。对日志进行审计是log4jINFO级别实现的。在默认配置下,在log4j.properties属性文件中的日志阈值被设为WARN,因而此项特性并未启用:

log4j.logger.org.apache.hadoop.hdfs.server.namenode.FSNamesystem.audit=WARN

可以通过将WARN替换成INFO来启动日志审计特性使每个HDFS事件均在namenode的日志文件中生成一行日志记录。下例说明如何记录在 目录执行的list status命令(列出指定目录下的文件/目录的状态):

2009-03-13 07:11:22,982 INFO org.apache.hadoop.hdfs.server.namenode.FSNamesystem. audit: ugi=tom,staff,admin ip=/127.0.0.1 cmd=listStatus src=/user/tom dst=null perm=null

为了不与namenode的其他日志项混在一起,最好配置log4j将审计日志写到单独的文件中。具体做法可以参考Hadoop的英文维基页面,网址为 http://wiki.apache.org/ hadoop/HowToConfigure 0

10.1.4工具

1. dfsadmin 工具

办工具用途较广,既可以査找HDFS状态信息,又可在HDFS上执 行管理操作。调用形式如下:

hadoop dfsadmin

仅当用户具有超级用户权限,才可以使用这个工具修改HDFS的状态。

10-2列举了部分的命令。要想进一步了解详情,可以使用-help 命令D


命令

-help

说明

显示指定命令的帮助,如果未指明命令,则显示所有命令的帮助

-report

显示文件系统的统计信息(类似于在网页界面上显示的内容), 以及所连接的各个datanode的信息

-metasave

将某些信息存储到Hadoop日志目录中的一个文件中,包括正 在被复制或删除的块的信息以及已连接的datanode列表

-safemode

改变或査询安全模式,参见10.1.2节对安全模式的讨论

-saveNamespace

将内存中的文件系统映像保存为一个新的/Wmage文件,重置 文件。该操作仅在安全模式下执行

-refreshNodes

更新允许连接到namenodedatanode列表,参见10.3.2节对

委任和解除节点的讨论

-upgradeProgress

获取有关HDFS升级的进度信息或强制升级。参见10.3.3对升 级的讨论

-finalizeUpgrade

移除datanodenamenode的存储目录上的旧版本数据。这个 操作一般在升级完成而且集群在新版本下运行正常的情况下执 行。参见10.3.3节对升级的讨论

-setQuota

设置目录的配额,即设置以该目录为根的整个目录树最多包含 多少个文件和目录。这项配置能有效阻止用户创建大量小文 件,从而保护namenode的内存(文件系统中的所有文件、目录 和块的各项信息均存储在内存中)

-clrQuota

清理指定目录的配额

-setSpaceQuota

设置目录的空间配额,以限制存储在目录树中的所有文件的总 规模。分别为各用户指定有限的存储空间很有必要

-clrSpaceQuota

清理指定的空间配额

-refreshServiceAcl

刷新namenode的服务级授权策略文件

 

 

2. fsck工具

Hadoop提供力&工具来检査HDFS中文件的健康状况。该工具会查找那些 在所有datanode中均缺失的块以及过少或过多复本的块。下例演示如何检 查某个小型集群的整个文件系统:

% hadoop fsck /

Status: HEALTHY

Total size: 511799225 B

Total dirs: 10

Total files: 22

Total blocks (validated): 22 (avg. block size 23263601 B)

Minimally replicated blocks: 22 (100.0 %)

Over-replicated blocks: 0 (0.0 %)

Under-replicated blocks: 0 (0.0 %)


Mis-replicated blocks: 0 (0.0 %)

Default replication factor: 3

Average block replication: 3.0

Corrupt blocks: 0

Missing replicas: 0 (0.0 %)

Number of data-nodes : 4

Number of racks: 1

The filesystem under path “、””is HEALTHY

fsck工具从给定路径(本例是文件系统的根目录)开始循环遍历文件系统的命 名空间,并检査它所找到的所有文件。对于检査过的每个文件,都会打印 一个点。在此过程中,该工具获取文件数据块的元数据并找出问题或 检查它们是否一致。注意,fsck工具只是从namenode获取信息,并不与任 datanode进行交互,因此并不真正获取块数据。

fsck输出文件的大部分内容都容易理解,以下仅说明部分信息。

过多复制的块指复本数超出最小复本级别的块。严格意义上讲, 这并非一个大问题,HDFS会自动删除多余复本。

仍需复制的块指复本数目低于最小复本级别的块。HDFS会自动为这些块创建新的复本,直到达到最小复本级别。可以调用hadoop dfsadmin -metasave指令了解正在复制的(或等待复制的)块的信息。

错误复制的块是指违反块复本放置策略的块(参见第72页的“复本的放置”小节)。例如,在最小复本级别为3的多机架集群中,如果一个块的三个复本都存储在一个机架中,则可认定该块的复本放置错误,因为一个块的复本要分散在至少两个机架中,以提高可靠性。 .

损坏的块指所有复本均已损坏的块。如果虽然部分复本损坏,但 至少还有一个复本完好,则该块就未损坏;namenode将创建新的复 本,直到达到最小复本级别。

缺失的复本指在集群中没有任何复本的块。

损坏的块和缺失的块是最需要考虑的,因为这意味着数据已经丢失了。默 认情况下,力以不会对这类块进行任何操作,但也可以让执行如下某 一项操作。

移动使用-move选项将受影响的文件移到HDFS/lost+found


录。这些受影响的文件会分裂成连续的块链表,可以帮助用户挽回 损失。

删除使用-delete选项删除受影响的文件。在删除之后,这些文

件无法恢复。

查找一个文件的数据块。fsck工具能够帮助用户轻松找到属于特定

文件的数据块。例如:

% hadoop fsck /user/tom/part-00007 -files -blocks -racks

/user/tom/part-00007 25582428 bytes, 1 block(s): OK

0. blk_-3724870485760122836_1035 len=25582428 repl=3 [/default-rack/10.251.43.2:50010, /default-rack/10.251.27.178:50010, /default-rack/10.251.123.163:50010]

输出内容表示文件包含一个块,该块的三个复本存储 在不同datanode所使用的三个选项的含义如下:

• -files选项显示第一行信息,包括文件名称、大小、块数量和健 康状况(是否有缺失的块)

• blocks选项描述文件中各个块的信息,每个块一行

• racks选项显示各个块的机架位置和datanode的地址

如果不指定任何参数,运行hadoop fsck命令会显示完整的使用说明。

3. datanode块扫描器

各个datanode运行一个块扫描器,定期检测本节点上的所有块,从而在客 户端读到坏块之前及时地检测和修复坏块。可以依靠DataBlockScanner 所维护的块列表依次扫描块,查看是否存在校验和错误。扫描器还使用节 流机制,来维持datanode的磁盘带宽(换句话说,块扫描器工作时仅占用一 小部分磁盘带宽)。

在默认情况下,块扫描器每隔三周(目卩504小时)就会检测块,以应对可能的 磁盘故障,该周期由dfs.datanode.scan.period.hours属性设置。损 坏的块被报给namenode,并被及时修复。.

用户可以访问 datanode 的网页(http://datanode:50075/blockScannerReport)来 获取该datanode的块检测报告。以下是一^份报告的范例,很容易理解:

Total Blocks : 21131

Verified in last hour : 70

Verified in last day : 1767


Verified in last week : 7360

Verified in last four weeks : 20057

Verified in SCAN_—PERIOD : 20057

Not yet verified : 1074

Verified since restart : 35912

Scans since restart : 6541

Scan errors since restart : 0

Transient scan errors : 0

Current scan rate limit KBps : 1024

Progress this period : 109%

Time left in cur period : 53.08%

通过指定 listblocks 参数,http://datanode:50075/blockScannerReport?Listblocks 在报告中列出该datanode上所有的块及其最新验证状态。下面节选部分内 容(由于页面宽度限制,报告中的每行内容被显示成两行):

blk_6035596358209321442 : status : ok type : none scan time : 0

not yet verified

blk—3065580480714947643 : status : ok type : remote scan time : 1215755306400

2008-07-11 05:48:26,400

blk_8729669677359108508 : status : ok type : local scan time : 1215755727345

2008-07-11 05:55:27,345

第一列是块ID,接下来是一些键/值对。块的状态(status)要么是failed(损 坏的),要么是ok(良好的),由最近一次块扫描是否检测到校验和来决定。 扫描类型(type)可以是local(本地的)、remote(远程的)或none(没有)。如 果扫描操作由后台线程执行,则是local;如果扫描操作由客户端或其他 datanode执行,则是remote;如果针对该块的扫描尚未执行,则是 none最后一项信息是扫描时间,从1970年1月1号午夜开始到扫描时间 为止的毫秒数,另外也提供更易读的形式。

4.均衡器

随着时间推移,各个datanode上的块分布会越来越不均衡。不均衡的集群 会降低MapReduce的本地性,导致部分datanode相对更加繁忙。应避免出 现这种情况。

均衡器(balancer)程序是_•个Hadoop守护进程,它将块从忙碌的datanode 移到相对空闲的datanode从而重新分配块。同时坚持块复本放置策略, 将复本分散到不同机架,以降低数据损坏率(参见3.6.3节)。它不断移动 块,直到集群达到均衡,即每个datanode的使用率(该节点上已使用的空间 与空间容量之间的比率)和集群的使用率(集群中已使用的空间与集群的空间


容量之间的比率)非常接近,差距不超过给定的阀值。可调用下面指令启动 均衡器:

% start-balancer.sh

threshold参数指定阈值(百分比格式),以判定集群是否均衡。该标记是 可选的;若不使用,默认阈值是10%。在任何时刻,集群中都只运行一个均 衡器。

均衡器会一直运行,直到集群变得均衡为止;之后,均衡器不会移动任何 块,将失去与namenode的联络。均衡器在标准日志目录中创建一个日志文 件,记录它所执行的每轮重新分配过程(每轮次输出一行)。以下是针对一个 小集群的日志输出:

Time Stamp Iteration# Bytes Already Moved Bytes Left To Move Bytes Being Moved Mar 18, 2009 5:23:42 PM 0 0 KB 219.21 MB 150.29 MB

Mar 18, 2009 5:27:14 PM 1 195.24 MB 22.45 MB 150.29 MB

The cluster is balanced. Exiting…

Balancing took 6.072933BB3333B33 minutes

为了降低集群负荷、避免干扰其他用户,均衡器被设计为在后台运行。在 不同节点之间复制数据的带宽也是受限的。默认值是很小的1 MB/s可以 通过如hdfs-site.xml文件中的dfs.balance.bandwidthPerSec属性重新设

(单位是字节)。

10.2监控

监控是系统管理的重要内容。在本节中,我们概述Hadoop的监控工具,看 看它们如何与外部监控系统相结合。

监控的目标在于检测集群在何时未提供所期望的服务。主守护进程是最需 要监控的,包括主namenode辅助namenodejobtracker我们可以预期 少数datanodetasktracker会出现故障,特别是在大型集群中。因此,需 要为集群预留额外的容量,即使有一小部分节点宕机,也不会影响整个系 统的运作。

除了以下即将介绍的工具之外,管理员还可以定期运行一些测试作业来检 査集群的健康状况。

能够监控Hadoop的工具(或方法)有很多,但限于篇幅,本书无法一一介


绍。例如,Chukwa®是一个数据集合,也是基于HDFSMapReduce的监 控系统,它在挖掘日志数据和发现大规模趋势方面有很大的优势。

10.2.1 曰志

所有Hadoop守护进程都会产生日志文件,这些文件非常有助于查明系统中 已发生的事件。9.4.2节在讨论系统日志文件时解释了如何配置这些文件。

1.设置日志级别

在故障排査过程中,若能够临时变更特定组件的日志的级别的话,将非常 有益。

可以通过Hadoop守护进程的网页(在守护进程的网页的//ogLeve/目录下) 改变任何log4j日志名称的日志级别。一般来说,Hadoop中的各个日志名 称分别对应一个执行相关日志操作的类名称。此外,也有例外情况,因此最好 从源代码中查找日志名称。

例如,为了启用JobTracker类日志调试特性,可以访问jobtracker的网页(http://jobtracker-host:50030/logLevel) org. apache • hadoop. mapred. JobTracker 属性设为DEBUG级別。

也可以通过以下命令实现上述目标:

% hadoop daemonlog -setlevel jobtracker-host:50030 \

org.apache.hadoop.mapred.DobTracker DEBUG

按照上述方式修改的日志级别会在守护进程重启时被复位,通常这也符合 用户预期。如果想永久性地变更日志级別,只需在配置目录下的log4jproperties文件中添加如下这行代码:

log4j.logger.org.apache.hadoop.mapred.JobTracker=DEBUG

2. 获取堆栈跟踪

Hadoop守护进程提供一个网页(网页界面的/stacks目录)对正在守护进程的 JVM中运行着的线程执行线程转储thread dump)。例如,可通过http://jobtracker-host:50030/stacks获得 jobtracker 的线程转储。


10.2.2  度量

HDFSMapReduce守护进程收集的事件和度量相关的信息,这些信息统 称为“度量”metric)。例如,各个datanode会收集以下度量(还有更多): 写入的字节数、块的复本数和客户端发起的读操作请求数(包括本地的和远 程的)。

度量从属于特定的上下文(context)。目前,Hadoop使用dfsmapred、rpc jvmm四个上下文。Hadoop守护进程通常在多个上下文中收集度量。例 如,datanode会分别为dfsrpcjvm上下文收集度量。

度量和计数器的差别在哪里?

主要区别是应用范围不同:度量由Hadoop守护进程收集,而计数器(参见 8.1节对计数器的讨论)先针对MapReduce任务进行采集,再针对整个作业 进行汇总。此外,用户群也不同,从广义上讲,度量为管理员服务,而计 数器主要为MapReduce用户服务。

二者的数据采集和聚集过程也不相同。计数器是MapReduce的特性, MapReduce系统确保计数器值由tasktracker产生,再传回jobtrackter最终 传回运行MapReduce作业的客户端。(计数器是通过RPC的心跳[heartbeat] 传播的,详情可以参见6.1.2节。)在整个过程中,tasktrackerjobtracker 都会执行汇总操作。

度量的收集机制独立于接收更新的组件。有多种输出度量的方式,包括本 地文件、GangliaJMX守护进程收集度量,并在输出之前执行汇总操作。

上下文指定发布单元。例如,可以选择只发布dfs上下文,而不发布jvm 下文。度量在conf/hadoop-metrics.properties文件中配置,默认情况下,所有上下文都被配置成不发布度量。下例显示一个默认的配置文件(已经移除 了注释):

dfs.class=org.apache.hadoop.metrics.spi.NullContext

mapred.class=org.apache.hadoop.metrics.spi.NullContext

jvm.class=org.apache.hadoop.metrics.spi.NullContext

rpc.class=org.apache.hadoop.metrics.spi.NullContext

该文件中的每一行分别配置一个不同的上下文,并且指定一个类来管理该 上下文中的度量。这种类必须实现了 MetricsContext接口;并且,正如


名称所描述的那样,NullContext类既不发布也不更新度量。

后面几个小节将介绍其他几个实现了 MetricsContext接口的类。

用户可以访问特定守护进程的/网页以浏览该守护进程所采集的原始 度量,这为调试带来了便利。例如,要想以纯文本方式浏览jobtracker 度量,可访问http://jobtracker-host:50030/metrics网页要想以json格式 进行浏览,则要访问http://jobtracker-host:50030/metrics?Format=json网页。

1.关于 FileContext

FileContext将度量写到一个本地文件中。它含有两个配置属性,即 fileNameperiod属性fileName指定待写入文件的绝对路径文件 > 属性period指定文件更新间隔(以秒为单位)。这两个属性都是可选 的;如果没有设置,则每隔五秒钟将度量写到标准输出。

待配置的属性名称的格式为:“上下文名称.属性名称”,中间用句点分 隔。例如,为了将jvm上下文转储到一个文件,我们将像下面这样更改其 配置:

jvm.class=org.apache.hadoop.metrics.file.FileContext jvm.fileName=/tmp/jvm_metrics.log

第一行将jvm上下文更改为使用FileContext类;第二行将jvm上下文的 fileName属性设置为一个临时文件。输出的日志文件也有两行,但限于页 面宽度,这里分成多行显示:

jvm.metrics: hostName=ip-10-250-59-159, processName=NameNodej sessionId=, gcCount=46, gcTimeMillis=394, logErrorW, logFatal=0, logInfo=59, logWarn=l, memHeapCommittedM=4.9375J memHeaptJsedM=2.5322647, memNonHeapCommittedM=18.25> ^ memNonHeapUsedM=ll.330269, threadsBlocked=0, threadsNew=0, threadsRunnable=6, threadsTerminated=0> threadsTimedWaiting=8, threadsWaiting=13 jvm.metrics: hostName=ip-10-250-59-159, processName=SecondaryNameNode, sessionId=, gcCount=36, gcTimeMillis=261, logError^e, logFatal=0, logInfo=18, logWarn=4, J memHeapCommittedM=5.4414062, memHeapUsedM=4.46756, memNonHeapCommittedM=18.25j memNonHeapUsedM=10.624519j threadsBlocked=0, threadsNevj=0j threadsRunnable=5, threadsTerminated=0j threadsTimedWaiting=4, threadsWaiting=2

®术语“上下文”(context)被赋予多种含义,既可以指代一个度量的集合(例如dfs 下文),也可以指代发布度量的类(例如NullContext类)。


尽管FileContext可在本地系统上调试程序,但并不适用大型集群。如果 在大型集群中使用该方法,输出文件会被分散到集群中各个节点,从而给 分析带来一定难度。

2.关于 GangliaContext

Ganglia是一个针对超大规模集群的开源的分布式监控系统,运行之后仅消耗各个节点上很少的资源。Ganglia通过 GangliaContext收集度量,例如CPU和内存的使用情况。用户也可以将 Hadoop度量添加到Ganglia

GangliaContext需要指定一个属性(即severs)来描述一系列Ganglia

务器,格式是由空格和(或)逗号分隔的主端口对。更多配置信息可以参 见 Hadoop 的英文维基页面,W\ it http: "wiki.apache.org/hadoop/ GangliaMetrics

10-2显示了从Ganglia获取的一类信息,即jobtracker队列中任务数量的 变化情况。

image.png 

 

10-2.jobtracker队列中的任务数(Ganglia获得)

3. 关于 NullContextWithUpdateThread

FileContextGangliaContext都将度量“推送”push)到一个外部系统。 但某些监控系统(特别是JMX)则需要从Hadoop系统中“拉取”pull)度量。 NullContextWithUpdateThread就是这样的一个类,它不向外部系统发布任

何度量,但会借助定时器定期刷新存储在内存中的度量值,以确保这些度 量在供其他系统使用时都是最新的。

除了 NullContext之外,所有实现了 MetricsContext接口的类都有自动 更新功能(这些类都使用period属性,默认值是5)。因此,只有在用户 无需向外部系统输出度量时,才会用到NullContextWithUpdateThread


类。例如,由于GangliaContext可以确保度量是最新的,因此用户在使 JMX时无需额外配置度量系统。后面将详细讨论JMX

4.关于 CompositeContext

CompositeContext类允许用户向多个上下文输出同一组度量。假设要将度量同时输出到FileContextGangliaContext则配置文件如下所示。

jvm.class=org.apache.hadoop.metrics.spi.CompositeContext jvm.arity=2

jvm.subl.class=org.apache.hadoop.metrics.file.FileContext jvm.fileName=/tmp/jvm_metrics.log

jvm.sub2.class=org.apache.hadoop.metrics.ganglia.GangliaContext jvm.servers=ip-10-250-59-159.ec2.internal:8649

属性arity用于指定子上下文的数量。在本例中有两个子上下文。在各个 子上下文中,属性名称都附带一个序号做后缀,例如jvm.subl.class jvm.sub2.class

10.2.3 Java 管理扩展(JMX)

Java 管理扩展(Java Management ExtensionsJMX)是一个标准的 Java API 可监控和管理应用。Hadoop包括多个托管bean(MBean),可以将Hadoop 量发布给支持JMX的应用。现有MBean能够发布在dfsrpc 下文中的度量,但无法发布mapred(在本书写就之际)和jvm上下文 的度量(因为JVM自带的JVM度量更为丰富)。这些Mbean如表10-3所示。

 10-3. Hadoop 中的 MBeans

 

MBean

NameNodeActivityMBean

守护进程

Namenode

度量

namenode的活动度量, 文件操作的执行次数

例如新建

FSNamesystemMBean

Namenode

namenode的状态度量, 接的datanode数量

例如已连

DataNodeActivityMBean

Datanode

datanode的活动度量, 字节数

例如已读

FSDatasetMBean

Datanode

datanode的存储度量, 储容量、空闲存储容量

例如总存

RpcActivityMBean

所有使用RPC的守护进 程》包括 namenodedatanode、jobtracker tasktracker

RPC统计信息,例如平均处理时 间等

 

 JDK自带一个名为JConsole的工具来浏览JVM中MBean。该工具可以浏览Hadoop的度量,如图10-3所示。

image.png

图10-3. JConsole的视图,显示正在本地化运行的namenode的文件系统状态的度量

尽管使用默认度量配置就可以通过JMX来查看Hadoop度量,但是除非用户摒弃NullContext并且改用其他MetricsContext实现类,否则这些度量值将不会自动更新。例如,如果用户仅仅通过JMX检测质量,则最好采用NullContextWithUpdateThread。

许多第三方的监控和报警系统均可查询MBean,因此通过这些外部系统使用JMX监控一个Hadoop集群就很平常,前提是启用远程访问JMX功能和合理设置集群的安全级别,包括密码认证,SSL连接和SSL客户端认证等。参考Jave官方文档深入料及如何配置这些选项。

可通过设置Java的系统属性来启用远程访问JMX的所有选项,即:编辑conf/hadoop-env.sh文件来进行设置。以下配置设置演示如何在NameNode(已经关闭SSL协议)启用密码认证的远程访问JMX。该步骤与其他Hadoop守护进程非常相似

image.png

image.png

文件jmxremoteword以纯文本格式列举出用户名和密码。JMX文档对 这个文件的格式有详细描述。

采用这种配置方案之后,即可使用JConsole浏览远程namenode上的 MBean此外,还可以选用JMX工具获取MBean的属性值。这类工具很 多,下例演示如何使用jmxquery命令行工具来获取仍需复制的块数量:

% ./check_jmx -U service:jmx:rmi:///jndi/rmi://namenode-host:8004/jmxrmi -0 \ hadoop:service=NameNode, name=FSNamesystemState -A UnderReplicatedBlocks \ -w 100 -c 1000 -username monitorRole -password secret

JMX OK – UnderReplicatedBlocks is 0

此命令在端口 8004与主机namenode-host之间建立JMX RMI连接,同时采 用给定的用户名和密码进行认证。该命令读取对象hadoop:service= NameNode,name=FSNamesystemState) UnderReplicatedBlocks 属性值,打印到控制台。选项wc分别指定该值的警告和关键级别:恰当的取值通常需要 在集群上操作一段时间之后才能得到。

一种常用方案是,在使用Ganglia的同时,使用Nagios这样的警告系统来 监控Hadoop集群。Ganglia擅长高效地收集大量度量,并以图形化界面呈 现;Nagios以及类似系统擅长在若干项度量的临界阈值被突破之后及时报警。

10.3维护

10-3.1日常管理过程

1. 元数据备份 


如果namenode的永久性元数据丢失或损坏,则整个文件系统无法使用。因 此,元数据备份非常关键。可以在系统中分别保存若干份不同时间的备份 (例如,1小时前、丨天前、丨周前或1个月前),以保护元数据。方法一是 直接保存这些元数据文件的复本;方法二是整合到namenode上正在使用的 文件中。


最直接的元数据备份方法是利用脚本文件定期将辅助namenodeprevious.checkpoint子目录存档,放到异地站点。注意,该子目录放在 fs.checkpoint.dir属性定义的目录之中。此外,还需测试复本的一致性。测试方法很简单,只要启动一个本地namenode守护进程,査看它是否 能够将力/wageec/to文件载入内存(例如,扫描namenode日志以获得操作成功信息)。


2. 数据备份


尽管HDFS已经充分考虑了如何可靠地存储数据,但是正如任何存储系统 一样,仍旧无法避免数据丢失。因此,备份机制就很关键。Hadoop中存储 着海量数据,判断哪些数据需要备份以及在哪里备份就极具挑战性。关键 在于为数据划分不同优先级。那些无法重新"生成的数据的优先级最高,这 些数据对业务非常关键。同理,可再生数据和一次性数据商业价值有限,所 以优先级最低,无需备份。

不要误以为HDFS的复本技术足以胜任数据备份任务。HDFS的程序批漏、硬件故障都可能导致复本丢失。尽管Hadoop的设计方案可 :确保硬件故障极不可能导致数据丢失,但是这种可能性无法完全排 ' 除,特别是软件bug和人工误操作情况在所难免。


再比较HDFS的备份技术和RAIDRAID可以确保在某一个RAID 盘片发生故障时数据不受损坏。但是,如果发生raid控制器故 障、软件纰漏(可能重写部分数据或整个磁盘阵列故障,数据肯定会丢失。


通常情况下,HDFS的用户目录还会附加若干策略,例如目录容量限制和夜 间备份等。用户需要熟悉相关策略,才可预料执行结果。

distcp是一个理想的备份工具,其并行的文件复制功能可以将备份文件存储 到其他HDFS集群(最好软件版本不同,以防Hadoop软件纰漏而丢失数据 或其他Hadoop文件系统(例如S3KFS)。此外,还可以用3.4节提到的方法将数据从HDFS导出到完全不同的存储系统中。

1. 文件系统检查(fsck)


建议定期地在整个文件系统上运行HDFS的fsck(文件系统检査)工具(例 如,每天执行),主动査找丢失的或损坏的块。参见10.1.5节的详细介绍。


2. 文件系统均衡器

定期运行均衡器工具(参见10.1.4节对均衡器的详细介绍),保持文件系统的 各个datanode比较均衡。

10.3.2委任和解除节点

Hadoop集群的管理员经常需要向集群中添加节点,或从集群中移除节点。 例如,为了扩大存储容量,需要委任节点。相反的,如果想要缩小集群规 模,则需解除节点。如果某些节点表现反常,例如故障率过高或性能过于 低下,则需要解除该节点。

通常情况下,节点同时运行datanode ,和tasktracker,因而两者一般同时被 委任或解除。

1. 委任新节点

委任一个新节点非常简单。首先,配置hdfs-sites.xml文件,指向namenode; 其次,配置文件,指向jobtracker;最后,启动datanode jobtracker守护进程。然而,预先指定一些经过审核的节点以从中挑选新节 点仍不失为一种好的方法。

随便允许一台机器以datanode身份连接到namenode是不安全的,因为该机 器很可能会访问未授权的数据。此外,这种机器并非真正的datanode,在集群的控制之下,随时可能停止,从而导致潜在的数据丢失。(想象一 下,如果有多台这类机器连接到集群,而且某一个块的全部复本恰巧只存 储在这类机器上,安全性如何?)即使这些机器都在本机构的防火墙之内, 这种做法的风险也很髙。如果配置错误,datanode(以及tasktracker)可能会 被所有集群管理。

被允许连接到namenode的所有datanode放在一个文件中,文件名称由 dfs. hosts属性指定。该文件放在namenode的本地文件系统中,每行对应 一个datanode的网络地址(由datanode报告 可以通过namenode的网页查看)。如果需要为一个datanode指定多个网络地址,可将多个网络地址放 在一行,由空格隔开。

类似的,可能连接到jobtracker的各个tasktracker也在同一个文件中指定 (该文件的名称由mapred.hosts属性指定。在通常情况下,由于集群中的 节点同时运行datanodetasktracker守护进程,dfs.hostsmapred.hosts会同时指向一个文件,即include文件。


dfs.hosts属性和mapred.hosts属性指定的(一个或多个)文件不同 于slavas文件。前者供namenodejobtracker使用,用于决定可以 连接哪些工作节点。Hadoop控制脚本使用slaves文件执行面向整个 集群范围的操作,例如重启集群等Hadoop守护进程从不使用 slaves 文件。


向集群添加新节点的步骤如下。

(1) 将新节点的网络地址添加到办文件中。

(2) 运行以下指令,将经过审核的一系列datanode集合更新至 namenode 信息: % hadoop dfsadmin -refreshNodes

(3) 运行以下指令,将经过审核的一系列tasktracker信息更新至 jobtracker

hadoop mradmin -refreshNodes

(4) 以新节点更新s/avM文件。这样的话,Hadoop控制脚本会将新节 点包括在未来操作之中。

(5) 启动新的 datanode  tasktracker

(6) 检查新的datanodetasktracker是否都出现在网页界面中。

HDFS不会自动将块从旧的datanode移到新的datanode以平衡集群。用户 需要自行运行均衡器,详情参考10.1.4节对均衡器的讨论。

2. 解除旧节点

HDFS能够容忍datanode故障,但这并不意味着允许随意终止datanode三复本策略为例,如果同时关闭不同机架上的三个datanode,则数据丢失的概率会非常高。正确的方法是:用户将拟退出的若干datanode告知 namenodeHadoop系统就可在这些datanode停机之前将块复制到其他datanode有了 tasktracker的支持,Hadoop对故障的容忍度更高。如果关闭一个正在 运行任务的tasktracker, jobtracker会检测到故障,并在其他tasktracker上 重新调度任务。

若要解除一个节点,则该节点需要出现在exclude文件。对于HDFS来说, 文件名称由dfs. hosts, exclude属性控制;对于MapReduce来说,文件 名称由mapred.hosts.exclude属性控制。这些文件列出若干未被允许连 接到集群的节点。通常情况下,这两个属性指向同一个文件。

判断一个tasktracker能否连接到jobtracker非常简单。仅当tasktracker出现include文件且不出现在exclude文件中时,才能够连接到jobtracker 意:如果未指定include文件,或文件为空,则意味着所有节点都 包含在include文件中。

HDFS的规则稍有不同。如果一个datanode同时出现在includeexclude 文件中,则该节点可以连接,但是很快会被解除委任。表10-4总结了 datanode的不同组合方式。与tasktracker类似,如果未指定include文件或文件为空,都意味着包含所有节点。

 10-4. HDFS  include 文件和 exclude 文件

节点是否出现翁/nc/tzc/e文件中

节点是否出现在exc/ude文件中

解释

节点无法连接

节点无法连接

节点可连接

.

节点可连接,将被解除

从集群中移除节点的步骤如下。

 (1) 将待解除节点的网络地址添加到exc/wde文件中,不更新include文件。

 (2) 执行以下指令,使用一组新的审核过的datanode来更新namenode 设置:

 % hadoop dfsadmin -refreshNodes

(3)使用一组新的审核过的datanode来更新jobtracker设置:

% hadoop mradmin -refreshNodes

(4) 转到网页界面,査看待解除datanode的管理状态是否已经变为“正 在解除Decommission In Progress),因为此时相关的 datanode  在被解除过程之中。这些datanode会把它们的块复制到其他datanode

(5) 当所有datanode的状态变为“解除完毕”Decommissioned)时,表 明所有块都已经复制完毕。关闭已经解除的节点。

(6) 从办文件中移除这些节点,并运行以下命令:

% hadoop dfsadmin -refreshNodes 

% hadoop mradmin -refreshNodes

(7) 从文件中移除节点。

10.3.3升级

升级HDFSMapReduce集群需要细致的规划,特別是HDFS的升级。如 果文件系统的布局的版本发生变化,升级操作会自动将文件系统数据和元数据迁移到兼容新版本的格式。与其他涉及数据迁移的过程相似,升级操 作暗藏数据丢失的风险,因此需要确保数据和元数据都已经备份完毕。参10.3.1节对日常管理过程的讨论。

规划过程最好包括在一个小型测试集群上的测试过程,以评估是否能够承 (可能的)数据丢失的损失。测试过程使用户更加熟悉升级过程、了解如何 配置本集群和工具集,从而为在产品集群上进行升级工作消除技术障碍。 此外,一个测试集群也有助于测试客户端的升级过程。用户可以阅读5.2.2 节对客户端兼容性的讨论。

如果文件系统的布局并未改变,升级集群就非常容易:在集群上安装新的 HDFSMapReduce(客户端也同步安装),关闭旧的守护进程,升级配置文 件,启动新的守护进程,令客户端使用新的库。整个过程是可逆的,换言之,也可以方便地还原到旧版本。

成功升级版本之后,还需要执行两个清理步骤。

(1)从集群中移除旧的安装和配置文件。


(2)在代码和配置文件中针对“被弃用”deprecation)警告信息进行 修复。


HDFS的数据和元数据升级

如果采用前述方法来升级HDFS且新旧HDFS的文件系统布局恰巧不同, namenode无法正常工作,在其日志文件中产生如下信息:

File system image contains an old layout version -16.

An upgrade to version -18 is required.

Please restart NameNode with -upgrade option.

最可靠的判定文件系统升级是否必要的方法是在一个测试集群做实验。

升级HDFS会保留前一版本的元数据和数据的复本,但这并不意味着需要 两倍的存储开销,因为datanode使用硬链接保存指向同一块的两个应用(分 别为当前版本和前一版本),从而能够在需要时方便地回滚到前一版本。需 要强调的是,系统回滚到旧版本之后,原先的升级改动都将被取消。

用户可以保留前一个版本的文件系统,但无法回滚多个版本。为了执行 HDFS数据和元数据上的另一次升级任务,需要删除前一版本,该过程被称 “定妥升级finalizing the upgrade)。一旦执行该操作,就无法再回滚到 前一个版本。

一般来说,升级过程可以忽略中间版本(例如,从0.18.3升级到0.20.0不需 要先升级到0.19.x)。但在某些情况下还是需要先升级到中间版本,这种情 况会在发布说明文件中清晰指出。

仅当文件系统健康时,才可升级,因此有必要在升级之前调用fsck工具全 面检査文件系统的状态(参见10.1.4节对fsck工具的讨论)。此外,最好保 留力d的输出报告,该报告列举了所有文件和块信息;在升级之后,再次运行力fsck新建一份输出报告并比较两份报告的内容。

在升级之前最好清空临时文件,包括HDFSMapReduce系统目录和本地 临时文件等。

综上所述,如果升级集群会导致文件系统的布局变化,则需要采用下述步 骤进行升级。

(1) 在执行升级任务之前,确保前一升级已经定妥。

(2) 关闭MapReduce ,终止在tasktracker上运行的任何孤儿任务 (orphaned task)。

(3) 关闭HDFS,并备份namenode目录。

(4) 在集群和客户端安装新版本的Hadoop HDFSMapReduce

(5) 使用upgrade选项启动HDFS

(6) 等待,直到升级完成。

(7) 检验HDFS是否运行正常。

(8) 启动 MapReduce

(9) 回滚或定妥升级任务(可选的)。

运行升级任务时,最好移除PATH环境变量下的Hadoop脚本,这样的话, 用户就不会混淆针对不同版本的脚本。通常可以为新的安装目录定义两个 环境变量。在后续指令中,我们定义了 OLD_hadoop_installNEW_HADOOP_INSTALL 两个环境变量。

启动升级为了执行升级,可运行以下命令(即前述的步骤5):

% $NEW_HADOOP_INSTALL/bin/start-dfs.sh -upgrade

该命令的结果是让namenode升级元数据,将前一版本放在名为的 新目录中:

${dfs.name.dir}/current/VERSION

/edits 

/fsimage 

/fstime

/previous/VERSION

    /edits

    /fsimage

    /fstime

类似地,datanode升级存储目录,保留原先的复本,将其存放在 previous目录中

等待,直到升级完成升级过程并非一蹴即就,可以用办〃查看升级 进度,升级事件同时也出现在守护进程的日志文件中,步骤(6):

% $NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -upgradeProgress status

Upgrade for version -18 has been completed.

Upgrade is not finalized.

查验升级情况显示升级完毕。在本阶段中,用户可以检査文件系统的状态,例如使用/fsck从一个基本的文件操作)检验文件和块,参见步骤(7)。检验 系统状态时,最好让HDFS进入安全模式(所有数据只读),以防止其他用户 修改数据。

回滚升级(可选的)如果新版本无法正确工作,可以回滚到前一版本,参见 步骤(9),前提是尚未定妥更新。

回滚操作会将文件系统的状态转回到升级之前的状态,同期所做的 任何改变都会丢失。换句话说,将回滚到文件系统的前一状态,而 非将当前的文件系统降级到前一版本。

首先,关闭新的守护进程:

% $NEW_HAD00P_IN5TALL/bin/stop-dfs.sh

其次,使用rollback选项启动旧版本的HDFS:

% $OLD_HADOOP_INSTALL/bin/start-dfs.sh -rollback

该命令会让namenodedatanode使用升级前的复本替换当前的存储目录。 文件系统返回之前的状态。

定妥升级(可选如果用户满意于新版本的HDFS,可以定妥升级,参见步 (9),以移除升级前的存储目录。 

一且升级定妥,就再也无法回滚到前一版本。

在执行新的升级任务之前,必须执行这一步:

% $NEW_HADOOP_INSTALL/bin/hadoop dfsadmin -finalizeUpgrade % $NEW_HADOOP__INSTALL/bin/hadoop dfsadmin -upgradeProgress status

There are no upgrades in progress.

现在,HDFS已经完全升级到新版本了。

转载请注明:全栈大数据 » 第10章 管理Hadoop

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址