问题场景：
1 、集群启动后，可以查看文件，但是上传文件时报错，打开 web 页面可看到 namenode 正处于 safemode 状态，怎么处理？
2 、 Namenode 服务器的磁盘故障导致 namenode 宕机，如何挽救集群及数据？
3 、 Namenode 是否可以有多个？ namenode 内存要配置多大？ namenode 跟集群数据存储能力有关系吗？
4 、文件的 blocksize 究竟调大好还是调小好？
……
1.NAMENODE 职责
NAMENODE职责：
负责客户端请求的响应
元数据的管理（查询，修改）
\
2.元数据管理
namenode对数据的管理采用了三种存储形式：
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件（可通过日志运算出元数据）
3.元数据存储机制
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注： 当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中
\
4.namenode工作机制
1 ） 第一阶段： namenode 启动
（ 1 ）第一次启动 namenode 格式化后，创建 fsimage 和 edits （在 namenode 所在结点的 hadooop/data 目录下）文件。如果不是第一次启动，直接加载编辑日志和镜像文件到内存。
（ 2 ）客户端对元数据进行增删改的请求
（ 3 ） namenode 记录操作日志，更新滚动日志。
（ 4 ） namenode 在内存中对数据进行增删改查
2 ）第二阶段： Secondary NameNode 工作
（ 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
补充：
1.checkpoint的附带作用
namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据
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>
2.namenode目录
默认namenode目录，fsemage等存储在data/tmp下。不安全，可以自定义设置
元数据目录说明
在第一次部署好Hadoop集群的时候，我们需要在NameNode（NN）节点上格式化磁盘：
$HADOOP_HOME/bin/hdfs namenode -format
格式化完成之后，将会在$dfs.namenode.name.dir/current目录下如下的文件结构
current/
|-- VERSION
|-- edits_*
|-- fsimage_0000000000008547077
|-- fsimage_0000000000008547077.md5
`-- seen_txid
其中的dfs.name.dir是在hdfs-site.xml文件中配置的，默认值如下：
<property>
<name>dfs.name.dir</name>
<value>file://${hadoop.tmp.dir}/dfs/name</value>
</property>
hadoop.tmp.dir是在core-site.xml中配置的，默认值如下
<property>
<name>hadoop.tmp.dir</name>
<value>/tmp/hadoop-${user.name}</value>
<description>A base for other temporary directories.</description>
</property>
\
修改namdenode文件目录
<property>
<name>dfs.name.dir</name>
<value>/home/hadoop/name1,/home/hadoop/name2</value >
</property>
注：重新启动hdfs以后，namenode的元数据，会同时往两块nam1和name2磁盘或文件夹里书写，两个文件数据一样，相当于备份。 同理datanode也可以配置多块磁盘或者文件，相当于扩容。可以同时往多个datanode磁盘书写数据，减少磁盘io压力。
\
dfs.namenode.name.dir属性可以配置多个目录，
如/data1/dfs/name,/data2/dfs/name,/data3/dfs/name,....。各个目录存储的文件结构和内容都完全一样，相当于备份，这样做的好处是当其中一个目录损坏了，也不会影响到Hadoop的元数据，特别是当其中一个目录是NFS（网络文件系统Network File System，NFS）之上，即使你这台机器损坏了，元数据也得到保存。
下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。
3. 镜像文件和编辑日志文件
namenode被格式化之后，将在/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current目录中产生如下文件
fsimage_0000000000000000000
fsimage_0000000000000000000.md5
seen_txid
VERSION
（1）Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含HDFS文件系统的所有目录和文件idnode的序列化信息。
（2）Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户端执行的所有写操作首先会被记录到edits文件中。
（3）seen_txid文件保存的是一个数字，就是最后一个edits_的数字
（4）每次Namenode启动的时候都会将fsimage文件读入内存，并从00001开始到seen_txid中记录的数字依次执行每个edits里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看成Namenode启动的时候就将fsimage和edits文件进行了合并。
2.oiv查看fsimage文件
（1）查看oiv和oev命令
[robot@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）案例实操
[robotu@hadoop102 current]$ pwd
/opt/module/hadoop-2.7.2/data/tmp/dfs/name/current
[robot@hadoop102 current]$ hdfs oiv -p XML -i fsimage_0000000000000000025 -o /opt/module/hadoop-2.7.2/fsimage.xml
[robot@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/fsimage.xml
将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。
3.oev查看edits文件
（1）基本语法
hdfs oev -p 文件类型 -i编辑日志 -o 转换后文件输出路径
（2）案例实操
[robot@hadoop102 current]$ hdfs oev -p XML -i edits_0000000000000000012-0000000000000000013 -o /opt/module/hadoop-2.7.2/edits.xml
[robot@hadoop102 current]$ cat /opt/module/hadoop-2.7.2/edits.xml
将显示的xml文件内容拷贝到eclipse中创建的xml文件中，并格式化。
\
4.下面对$dfs.namenode.name.dir/current/目录下的文件进行解释。
namespaceID=934548976
clusterID=CID-cdff7d73-93cd-4783-9399-0a22e6dce196
cTime=0
storageType=NAME_NODE
blockpoolID=BP-893790215-192.168.24.72-1383809616115
layoutVersion=-47
\
（1）、namespaceID是文件系统的唯一标识符，在文件系统首次格式化之后生成的；
（2）、storageType说明这个文件存储的是什么进程的数据结构信息（如果是DataNode，storageType=DATA_NODE）；
（3）、cTime表示NameNode存储时间的创建时间，由于我的NameNode没有更新过，所以这里的记录值为0，以后对NameNode升级之后，cTime将会记录更新时间戳；
（4）、layoutVersion表示HDFS永久性数据结构的版本信息， 只要数据结构变更，版本号也要递减，此时的HDFS也需要升级，否则磁盘仍旧是使用旧版本的数据结构，这会导致新版本的NameNode无法使用；
（5）、clusterID是系统生成或手动指定的集群ID，在-clusterid选项中可以使用它；如下说明
\
- 使用如下命令格式化一个Namenode：
$HADOOP_HOME/bin/hdfs namenode -format [-clusterId <cluster_id>]
选择一个唯一的cluster_id，并且这个cluster_id不能与环境中其他集群有冲突。如果没有提供cluster_id，则会自动生成一个唯一的ClusterID。
b、使用如下命令格式化其他Namenode：
$HADOOP_HOME/bin/hdfs namenode -format -clusterId <cluster_id>
c、升级集群至最新版本。在升级过程中需要提供一个ClusterID，例如：
$HADOOP_PREFIX_HOME/bin/hdfs start namenode --config $HADOOP_CONF_DIR -upgrade -clusterId <cluster_ID>
如果没有提供ClusterID，则会自动生成一个ClusterID。
（6）、blockpoolID：是针对每一个Namespace所对应的blockpool的ID，上面的这个BP-893790215-192.168.24.72-1383809616115就是在我的ns1的namespace下的存储块池的ID，这个ID包括了其对应的NameNode节点的ip地址。
\
2、$dfs.namenode.name.dir/current/seen_txid非常重要，是存放transactionId的文件，format之后是0，它代表的是namenode里面的edits_*文件的尾数，namenode重启的时候，会按照seen_txid的数字，循序从头跑edits_0000001~到seen_txid的数字。所以当你的hdfs发生异常重启的时候，一定要比对seen_txid内的数字是不是你edits最后的尾数，不然会发生建置namenode时metaData的资料有缺少，导致误删Datanode上多余Block的资讯。
\
3、$dfs.namenode.name.dir/current目录下在format的同时也会生成fsimage和edits文件，及其对应的md5校验文件
补充：seen_txid
文件中记录的是edits滚动的序号，每次重启namenode时，namenode就知道要将哪些edits进行加载edits
\
