hadoop主节点(NameNode)备份策略以、恢复方法、操作步骤

本文详细解析HDFS中Checkpoint机制的作用与实现过程,包括edits和fsimage文件的功能、SecondaryNameNode的工作原理及其配置方法,同时介绍了如何通过CheckpointNode和BackupNode进行故障恢复。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、dits和fsimage 

    首先要提到两个文件edits和fsimage,下面来说说他们是做什么的。

  • 集群中的名称节点(NameNode)会把文件系统的变化以追加保存到日志文件edits中。
  • 当名称节点(NameNode)启动时,会从镜像文件 fsimage 中读取HDFS的状态,并且把edits文件中记录的操作应用到fsimage,也就是合并到fsimage中去。合并后更新fsimage的HDFS状态,创建一个新的edits文件来记录文件系统的变化

    那么问题来了,只有在名称节点(NameNode)启动的时候才会合并fsimage和edits,那么久而久之edits文件会越来越大,特别是大型繁忙的HDFS集群。这种情况下,由于某种原因你要重启名称节点(NameNode),那么会花费很长的时间去合并fsimge和edits,然后HDFS才能运行。


二、Secondary NameNode 

    目前使用的版本hadoop-0.20.2可以使用Secondary NameNode来解决上面的问题。Secondary NameNode定期合并fsimage和edits日志,把edits日志文件大小控制在一个限度下。因为内存需求和NameNode差不多(On the same order),所以Sencondary NameNode通常要运行在另外个机器上。

    secondary NameNode配置在conf/masters文件,启动命令:bin/start-dfs.sh(如果你使用不建议的start-all.sh也是会启动的)。


三、什么时候checkpiont 

secondary NameNode 什么时候执行checkpoint来合并fsimage和eidts。呢?有两个配置参数控制:

  • fs.checkpoint.period 指定两次checkpoint的最大时间间隔,默认3600秒。
  • fs.checkpoint.size    规定edits文件的最大值,一旦超过这个值则强制checkpoint,不管是否到达最大时间间隔。默认大小是64M。

     secondary NameNode 保存最后一次checkpoint的结果,存储结构和主节点(NameNode)的一样,所以主节点(NameNode)可以随时来读取。


    如果你没有启动secondary NameNode 那么可以试试 bin/hadoop secondarynamenode -checkpoint 甚至 bin/hadoop secondarynamenode -checkpoint force. 看看生成的文件。

 

    checkpoint可以解决重启NameNode时间过长的弊端。另外还有偏方:


四、Import Checkpoint(恢复数据) 

    如果主节点挂掉了,硬盘数据需要时间恢复或者不能恢复了,现在又想立刻恢复HDFS,这个时候就可以import checkpoint。步骤如下:

  • 拿一台和原来机器一样的机器,包括配置和文件,一般来说最快的是拿你节点机器中的一台,立马能用(部分配置要改成NameNode的配置)
  • 创建一个空的文件夹,该文件夹就是配置文件中dfs.name.dir所指向的文件夹。
  • 拷贝你的secondary NameNode checkpoint出来的文件,到某个文件夹,该文件夹为fs.checkpoint.dir指向的文件夹
  • 执行命令bin/hadoop namenode -importCheckpoint

     这样NameNode会读取checkpoint文件,保存到dfs.name.dir。但是如果你的dfs.name.dir包含合法的fsimage,是会执行失败的。因为NameNode会检查fs.checkpoint.dir目录下镜像的一致性,但是不会去改动它。 

    值得推荐的是,你要注意备份你的dfs.name.dir和 ${hadoop.tmp.dir}/dfs/namesecondary。


五、Checkpoint Node 和 Backup Node 


在后续版本中hadoop-0.21.0,还提供了另外的方法来做checkpoint:Checkpoint Node 和 Backup Node。则两种方式要比secondary NameNode好很多。所以 The Secondary NameNode has been deprecated. Instead, consider using the Checkpoint Node or Backup Node.

Checkpoint Node像是secondary NameNode的改进替代版,Backup Node提供更大的便利,这里就不再介绍了。

上面是理论,下面的具体操作。


1.修改conf/core-site.xml

增加

复制代码
<property> 
<name>fs.checkpoint.period</name> 
<value>3600</value> 
<description>The number of seconds between two periodic checkpoints. </description> 
</property> 
<property> 
<name>fs.checkpoint.size</name> 
<value>67108864</value> 
<description>The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs.checkpoint.period hasn't expired. </description> 
</property> 

<property> 
<name>fs.checkpoint.dir</name> 
<value>/data/work/hdfs/namesecondary</value> 
<description>Determines where on the local filesystem the DFS secondary name node should store the temporary images to merge. If this is a comma-delimited list of directories then the image is replicated in all of the directories for redundancy. </description> 
</property>
复制代码

fs.checkpoint.period表示多长时间记录一次hdfs的镜像。默认是1小时。 
fs.checkpoint.size表示一次记录多大的size,默认64M

2.修改conf/hdfs-site.xml

增加

<property> 
<name>dfs.http.address</name> 
<value>master:50070</value> 
<description> The address and the base port where the dfs namenode web ui will listen on. If the port is 0 then the server will start on a free port. </description> 
</property>

0.0.0.0改为namenode的IP地址

3.重启hadoop,然后检查是否启动是否成功

登录secondarynamenode所在的机器,输入jps查看secondarynamenode进程 
进入secondarynamenode的目录/data/work/hdfs/namesecondary 
正确的结果: 
如果没有,请耐心等待,只有到了设置的checkpoint的时间或者大小,才会生成。

4.恢复

制造namenode宕机的情况 
1) kill 掉namenode的进程

[root@master name]# jps 
11749 NameNode 
12339 Jps 
11905 JobTracker 
[root@master name]# kill 11749

 

2)删除dfs.name.dir所指向的文件夹,这里是/data/work/hdfs/name

[root@master name]# rm -rf *

删除name目录下的所有内容,但是必须保证name这个目录是存在的

 

3)从secondarynamenode远程拷贝namesecondary文件到namenode的namesecondary

[root@master hdfs]# scp -r slave-001:/data/work/hdfs/namesecondary/ ./

4)启动namenode

[root@master /data]# hadoop namenode –importCheckpoint

正常启动以后,屏幕上会显示很多log,这个时候namenode就可以正常访问了

5)检查

使用hadoop fsck /user命令检查文件Block的完整性

hadoop fsck /

6)停止namenode,使用crrl+C或者会话结束

7)删除namesecondary目录下的文件(保存干净) 

[root@master namesecondary]# rm -rf *


8)正式启动namenode

[root@master bin]# ./hadoop-daemon.sh start namenode

恢复工作完成,检查hdfs的数据

 

9)balancer

在使用start-balancer.sh时, 
默认使用1M/S(1048576)的速度移动数据(so slowly...) 
修改hdfs-site.xml配置,这里我们使用的是20m/S

<property> 
<name>dfs.balance.bandwidthPerSec</name> 
<value>20971520</value> 
<description> Specifies the maximum bandwidth that each datanode can utilize for the balancing purpose in term of the number of bytes per second. </description> 
</property>

然后结果是导致job运行变得不稳定,出现一些意外的长map单元,某些reduce时间处理变长(整个集群负载满满的情况下,外加20m/s的balance),据说淘宝的为10m/s,需要调整后实验,看看情况如何。


hadoop balancer -threshold 5





<think>好的,我现在需要帮助用户解决Hadoop集群中主节点启动成功但NameNode未启动的问题。首先,我应该回顾用户提供的引用内容,看看有哪些可能的原因和解决方法。 根据引用[1],用户提到手动创建dfs.name.dir和dfs.data.dir路径可能会导致问题,正确的做法是让Hadoop自动创建这些目录。这可能是一个常见原因,需要检目录权限和配置是否正确。 引用[4]指出,删除tmp和logs目录并重新创建可能解决问题。这说明文件损坏或残留文件可能影响NameNode启动。用户可能需要清理旧数据并重新格式化。 接下来,我需要整理可能的原因和对应的解决步骤。首先检日志文件,这是定位问题的关键。然后检核心配置文件如hdfs-site.xml和core-site.xml,确认路径是否正确。目录权限问题也很重要,确保Hadoop用户有读写权限。 格式化NameNode可能也是必要的,特别是初次启动或配置更改后。同时,检防火墙和端口占用,确保50070和9000端口可用。Secondary NameNode的状态也可能影响主节点,需要确认其配置是否正确。 最后,如果问题仍然存在,可能需要检Java环境和Hadoop版本兼容性,或者尝试重新安装Hadoop。整个过程需要逐步排,从日志入手,逐步验证每个配置项和步骤的正确性。</think>### Hadoop主节点NameNode未启动的原因及排步骤 #### 一、可能原因分析 1. **元数据目录配置错误** - 检$hdfs-site.xml$中的$dfs.namenode.name.dir$路径配置是否正确,该路径需要可读写权限[^1][^4] - 验证$core-site.xml$中的$hadoop.tmp.dir$配置是否有效 2. **残留文件冲突** - 之前手动创建的元数据目录可能残留旧文件,导致初始化失败[^1] - 未格式化NameNode直接启动(常见于首次启动) 3. **日志文件阻塞** - 旧的logs目录可能包含冲突日志文件 - 检$HADOOP_HOME/logs/namenode*.log$的错误日志 4. **端口占用冲突** - 默认50070(Web UI)和9000(RPC)端口被占用 - 使用$netstat -tunlp | grep 50070$检测端口占用 #### 二、标准解决流程 ```bash # 1.清理残留文件(所有节点执行) cd $HADOOP_HOME rm -rf tmp/ logs/ # 2.重建目录(主节点执行) mkdir -p /path/to/namenode/dir # 对应dfs.namenode.name.dir配置路径 chmod 755 /path/to/namenode/dir # 3.格式化NameNode(仅首次启动) hdfs namenode -format --force # 4.看启动日志(实时监控) tail -f $HADOOP_HOME/logs/hadoop-*-namenode-*.log # 5.单独启动NameNode hadoop-daemon.sh start namenode ``` #### 三、高级排技巧 1. **日志分析要点** - 找"FATAL"级别日志 - 关注$java.io.IOException$类错误 - 检堆栈跟踪中的文件路径 2. **配置文件验证** ```xml <!-- 示例正确配置 --> <property> <name>dfs.namenode.name.dir</name> <value>file:/usr/local/hadoop/namenode</value> </property> <property> <name>hadoop.tmp.dir</name> <value>/usr/local/hadoop/tmp</value> </property> ``` 3. **权限验证命令** ```bash # 看目录所有者 ls -ld /path/to/namenode/dir # 递归修改权限(Hadoop运行用户为hadoop) chown -R hadoop:hadoop /usr/local/hadoop ``` 4. **Secondary NameNode关联检** ```bash # 检secondary节点状态 hdfs haadmin -getServiceState nn1 ``` #### 四、特殊场景处理 1. **安全模式问题** ```bash hdfs dfsadmin -safemode get # 看安全模式状态 hdfs dfsadmin -safemode leave # 强制退出安全模式 ``` 2. **JournalNode异常** ```bash # 检JournalNode服务 jps | grep JournalNode ``` 3. **HA高可用配置错误** ```bash # 验证HA状态 hdfs haadmin -getAllServiceState ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值