bug：配置secondarynamenode && 斯塔尼亚聊天记录

 

secondary namenoded 配置很容易被忽视，如果jps检查都正常，大家通常不会太关心，除非namenode发生问题的

时候，才会想起还有个secondary namenode，它的配置共两步：

 

1. 集群配置文件conf/master中添加secondarynamenode的机器名
2. 修改/添加 hdfs-site.xml中如下属性：

 <property>

    <name>dfs.http.address</name>

    <value>{your_namenode_ip}: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> 

 

 

这两项配置OK后，启动集群。进入secondary namenode 机器，检查fs.checkpoint.dir（core-site.xml文件，默认为${hadoop.tmp.dir}/dfs/namesecondary）目录同步状态是否和namenode一致的。

 

如果不配置第二项则，secondary namenode同步文件夹永远为空，这时查看secondary namenode的log显示错误为：

2011-06-09 11:06:41,430 INFO org.apache.hadoop.hdfs.server.common.Storage: Recovering storage directory /tmp/hadoop-hadoop/dfs/namesecondary from failed checkpoint.

2011-06-09 11:06:41,433 ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: Exception in doCheckpoint:

2011-06-09 11:06:41,434 ERROR org.apache.hadoop.hdfs.server.namenode.SecondaryNameNode: java.net.ConnectException: Connection refused

 

可能用到的core-site.xml文件相关属性：

配置项part.1 :

<property>

    <name>fs.checkpoint.period</name>

    <value>300</value>

    <description>The number of seconds between two periodic checkpoints.</description>

</property>

<property>

    <name>fs.checkpoint.dir</name>

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

    <description>Determines where on the local filesystem the DFS secondaryname node should store the temporary images to merge.If this is a comma-delimited list of directories then the image isreplicated in all of the directories for redundancy.决定在本地文件系统DFS secondaryname节点存储临时图像合并。如果这是一个用逗号分隔的目录列表将图像复制在所有的目录冗余。

     </description>

</property>

 

 

---

以下是和斯塔尼亚的聊天记录：

他说上面那个错误是：做检查点的时候报错了

他： 配置项part.1 还有点用，但上面说开一个web端口就能影响secondary……我觉得不可能 。就好比你服务器硬盘挂了，然后你在另一块硬盘上起了个tomcat，告诉你这块硬盘就好了……

<property>
    <name>hadoop.tmp.dir</name>
    <value>/data/hadoop/tmp</value>
</property>

你再core-site中也配置一下这个，值改成自己的

我：hadoop中的checkpoint是什么作用啊 。我看oracle中也有个这个概念，是一样的意思吗？

他：这个checkpoint有点类似于元数据的备份，secondarynamenode这个名字起的很有迷惑性， 实际上是这样的：namenode中分为fsimage和edit，正常内存中记录的块情况会被写成edit，edit到一定大小会被归档为fsimage，在这个过程中会去掉一些冗余的部分，但这个过程你也看到可能需要一些资源，让namenode去做的话可能会压力较大，于是这个过程被交给了secondarynamenode，所以说，其实secondarynamenode与其说是一个备份namenode，不如说是一个辅助namenode，

它的作用和namenode并不同，也说不上什么明显的归档作用，毕竟它的checkpoint只发生在合并时，确实namenode出问题的时候能用它回复，但无疑会丢失东西

dfs.namenode.checkpoint.dir    file://${hadoop.tmp.dir}/dfs/namesecondary    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.

dfs.namenode.checkpoint.edits.dir    ${dfs.namenode.checkpoint.dir}

我：这个情况是这样的：我的datanode中原来有数据，之后我又重新format了一下namenode，再start-dfs.sh时datanode就起不来了

他：那个是你datanode中数据没删除干净，可能是你重新format的时候datanode是关闭着的，把datanode下的所有数据，包括配置tmp下所有数据都删除， 就好了

我：重新format的时候datanode还要开着？我format后tmp下的文件没有删掉。

他：是这样的，hadoop的datanode ，在第一次连接进集群的时候会产生一个认证信息 ，以标志它属于这个集群，而不是另一个集群 ，否则会造成数据污染，但如果你格式化了namenode、datanode启动后还在找原来的namenode，（注释：然后我发了解决这个datanode起不来的办法的第二条，他说这个方法是对的。）它在检测自己被介入其他集群的时候，会关闭自己 ，以保证不会污染数据，这个现象还经常在hbase中见到 ，如果重做hbase的时候在zookeeper中没删除znode，就会经常见到“hmaster开启后过一会又abort”或者regionserver这样的情况，你在群里留一下，基本每个月我都能见到俩，问我hbasemaster起来后又关闭是怎么回事的人。

大概就是说这样：每个子节点第一次加入集群的时候都会认证自己的子节点，自己的主节点，之后它就只认这一个主节点，接入错了就会自动关闭，如果你格式化了namenode，就跟重装了一样，子节点就认不出来自己主节点了，就觉得你介入错了，就关机了