Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
MapReduce >> mail # user >> Is it necessary to run secondary namenode when starting HDFS?


+
Ivan Ryndin 2012-12-17, 17:04
+
Bryan Beaudreault 2012-12-17, 17:12
+
Ivan Ryndin 2012-12-17, 17:23
+
Michael Segel 2012-12-17, 17:42
+
Harsh J 2012-12-17, 17:09
+
Ivan Ryndin 2012-12-17, 17:22
+
Patai Sangbutsarakum 2012-12-17, 18:52
Copy link to this message
-
Re: Is it necessary to run secondary namenode when starting HDFS?
I agree with Michael. Skipping the SNN daemon is really a bad idea when you
are dealing something real.

Best Regards,
Tariq
+91-9741563634

On Tue, Dec 18, 2012 at 12:22 AM, Patai Sangbutsarakum <
[EMAIL PROTECTED]> wrote:

>  > is it necessary to run secondary namenode when starting HDFS?
> I would say it's not necessary. I did skip it when I first played with
> Hadoop.
>
>   From: Ivan Ryndin <[EMAIL PROTECTED]>
> Reply-To: <[EMAIL PROTECTED]>
> Date: Mon, 17 Dec 2012 21:04:49 +0400
> To: <[EMAIL PROTECTED]>
> Subject: Is it necessary to run secondary namenode when starting HDFS?
>
>  Hi all,
>
>  is it necessary to run secondary namenode when starting HDFS?
> I am dealing with Hadoop 1.1.1.
> Looking at script $HADOOP_HOME/bin/start_dfs.sh
> There are next lines in this file:
>
>  # start dfs daemons
> # start namenode after datanodes, to minimize time namenode is up w/o data
> # note: datanodes will log connection errors until namenode starts
> "$bin"/hadoop-daemon.sh --config $HADOOP_CONF_DIR start namenode
> $nameStartOpt
> "$bin"/hadoop-daemons.sh --config $HADOOP_CONF_DIR start datanode
> $dataStartOpt
> "$bin"/hadoop-daemons.sh --config $HADOOP_CONF_DIR --hosts masters start
> secondarynamenode
>
>   So, will HDFS work if I turn off starting of secondarynamenode ?
>
>  I do ask this because I am playing with Hadoop on two-node cluster only
> (and machines in cluster do not have much RAM and disk space), and thus
> don't want to run unnecessary processes.
>
>  --
> Best regards,
> Ivan P. Ryndin,
>
>