NameNode元数据管理机制（six day second）

NameNode元数据管理机制：

记录元数据如果是操作一个文件的话是很不方便的，因为这个里面的数据是经常要改动的（增删改查）

为了方便地去修改这些数据，所以不用文件形式去存，而是放在内存里面（元数据放在内存里），在内存里可以用java对象来表示这些东西，java会设计一个对象，对象里面封装了一种数据结构---树，来表示目录结构，增删改查就很明显/分别。

问题来了，如果宕调，数据会全部丢失，所以定期需要备份到磁盘，比较安全，对象-->磁盘，对象序列化到磁盘的nameNode工作目录（fsimage文件），由于对象有很大的数据描述，不能改一点东西就序列化。所以设置成隔一段时间序列化一次，但是隔的这段时间宕机还是会丢失，所以每做一个操作，引起元数据变化的同时，记录引起元数据变化操作（日志，如果做了操作，追加日志即可，edits日志文件）。这样有一个好处，如果namenode挂了，下次重启的时候可以恢复元数据【首先把最后一次序列化的东西反序列化成对象，然后再用一个算法解析日志看做过什么操作，然后相应的去修改元数据，根据日志一条一条顺序重放即可】，当日志文件越来越大的时候会很难解析，所以把日志定期/定大小切割，但是问题又来了，日志切好多的时候，如果宕机重启去解析许多日志会很慢，等很久才能正常工作。

Secondary NameNode（另起一台机器）:

定期的把namenode上的fsimage文件下载到它的本地磁盘，同时把edits文件下载到它的本地磁盘，然后加载，反序列化fsimage文件到内存里（变成元数据目录树，）变成一个对象（内存元数据对象），然后写一个程序去读edits文件，更新元数据，，接下来这个内存元数据会变成新的，然后把新序列化到磁盘以后的上传到namenode的工作目录，总是会保留最近的两个，默认情况下是一个小时做一次合并。这个机制叫做checkpoint机制。

第一次checkpoint需要下载fsimage镜像文件，以后就不用下载了，因为自己的机器上就已经有了。

1. 什么是元数据？

hdfs的目录结构及每一个文件的块信息（块的id，块的副本数量，块的存放位置<datanode>），元数据由namenode负责管理

     2、namenode把元数据记录在哪里？

namenode的实时的完整的元数据存储在内存中；

namenode还会在磁盘中（dfs.namenode.name.dir）存储内存元数据在某个时间点上的镜像文件；

namenode会把引起元数据变化的客户端操作记录在edits日志文件中；

 

secondary namenode启动位置的配置

<property>

  <name>dfs.namenode.secondary.http-address</name>

  <value>0.0.0.0:50090</value>

</property>

把默认值改成你想要的机器主机名即可

 

secondarynamenode保存元数据文件的目录配置：

<property>

  <name>dfs.namenode.checkpoint.dir</name>

  <value>file://${hadoop.tmp.dir}/dfs/namesecondary</value>

</property>

改成自己想要的路径即可：/root/dfs/namesecondary

记几个必掌握单词：
handshake  握手
parallel 并行
directories  目录
upgrade  更新
active 激活、活跃的
assign 指派，分配
unassigned  未指派的
incompatible 不兼容的
cluster  集群
clusterID  集群id