一、概述
hadoop的namenode和secondarynamenode：
1. namenode负责
负责客户端请求的响应
元数据的管理（查询，修改）
2. 元数据管理
namenode对数据的管理采用了三种存储形式：
内存元数据(NameSystem)
磁盘元数据镜像文件
数据操作日志文件（可通过日志运算出元数据）
3. 元数据存储机制
A、内存中有一份完整的元数据(内存meta data)
B、磁盘有一个“准完整”的元数据镜像（fsimage）文件(在namenode的工作目录中)
C、用于衔接内存metadata和持久化元数据镜像fsimage之间的操作日志（edits文件）注：当客户端对hdfs中的文件进行新增或者修改操作，操作记录首先被记入edits日志文件中，当客户端操作成功后，相应的元数据会更新到内存meta.data中
4. 元数据的checkpoint
每隔一段时间，会由secondary namenode将namenode上积累的所有edits和一个最新的fsimage下载到本地，并加载到内存进行merge（这个过程称为checkpoint）
checkpoint过程：
1.如果客户端涉及到元数据的更新（读数据不算更新，比如更改文件的名称、路径等、删除文件，增删改操作）。注意客户端不能更改文件内容，顶多可以追加操作。会有操作日志到NameNode的记录日志中。
2.随着元数据的操作记录日志增多，secondary NameNode 也会定期的去请求NameNode是否需要checkpoint.
3.如果得到应答，namenode会滚动当前的日志edits.inprogress,将当前记录的edits和namenode中的fsimage下载到secondary namenode中。
4.secondary namenode会将其两者加载到内存合并，dump成新的image文件，重新上传到namenode中，重命名为新的fsimage.
5.checkpoint时，会把正在写的edits滚动一下，然后将fsimage和日志下载到secondary namenode机器，只有第一次hdfs初始化时才下载fsimage,这时的文件操作没有那么大的数据量。以后只负责下载日志文件，合并旧的fsimage
注意：NameNode工作的时候元数据的查询都是找内存，只有NameNode宕机，内存中没有元数据，那hdfs重新启动的时候。数据就从fsimage和edits这两个文件中加载。
namenode和secondary namenode的工作目录存储结构完全相同，所以，当namenode故障退出需要重新恢复时，可以从secondary namenode的工作目录中将fsimage拷贝到namenode的工作目录，以恢复namenode的元数据。
二、配置
修改文件：
hdfs-site.xml
<property>
<name>dfs.namenode.secondary.http-address</name>
<value>10.10.89.219:</value>
</property>
<property>
<name>dfs.namenode.checkpoint.dir</name>
<value>file:/data/hadoop-2.7./checkpoint</value>
</property>
<property><property>
<name>dfs.namenode.checkpoint.period</name>
<value></value>
</property>
<property>
<name>dfs.namenode.checkpoint.txns</name>
<value></value>
</property>
所有节点都要修改，当然可以指定secondarynamenode的启动节点为其他节点。