Hadoop secondarynamenode and namenode

1. Overview

Simply put, it is easy for beginners to think That secondarynamenode (SNN) is a hot standby process of namenode (NN.
Actually not. SNN is an integral part of the HDFS architecture, but it is often misunderstood by its name. In fact, it is used to save the backup of HDFS metadata information in namenode, and reduce the restart time of namenode. You still need to do some work to configure and use SNN correctly in the hadoop process.

In the default configuration of hadoop, The SNN process runs on the machine named namenode by default. However, if an error occurs on this machine, it is a great disaster to restore the HDFS file system. A better way is to configure the SNN process to run on another machine.

In hadoop, namenode is responsible for the persistent storage of HDFS metadata and processing the interaction feedback from clients on various HDFS operations. To ensure interaction speed, the metadata of the HDFS file system is loaded into the memory of the namenode machine and stored to the disk for persistent storage.

To ensure that this persistence process does not become the bottleneck of HDFS operations, hadoop adopts the following method: No snapshot of the current file system is persisted, the list of HDFS operations in the recent period will be saved to an editlog file in namenode. When the namenode is restarted, in addition to the load fsimage accident, the HDFS operation recorded in the editlog file will be replaced to restore the final state before the HDFS restart.

Secondarynamenode periodically merges the HDFS operations recorded in the editlog into a checkpoint, and then clears the editlog. Therefore, the restart of namenode will load the latest checkpoint and replay the HDFS operations recorded in the editlog. Because the editlog records the list of operations from the last checkpoint to the present, so it will be relatively small. If there is no periodic merge process for SNN, it will take a long time to restart namenode each time. In this way, periodic merge can reduce the restart time. It also guarantees the integrity of the HDFS system.
This is what secondarynamenode does. Therefore, SNN does not share the stress on HDFS interactive operations on namenode. Even so, when the namenode machine goes down or the namenode process goes wrong, the namenode daemon process can manually copy a metadata copy from the SNN to restore the HDFS file system.
The reason for running the SNN process on a non-namenode machine is as follows:

Scalability: to create a new HDFS snapshot, You need to copy all the metadata information loaded to the memory in namenode. This operation requires the same memory as the memory occupied by namenode, the memory allocated to the namenode process is actually a limitation on the HDFS file system. If the distributed file system is very large, the memory of the namenode machine may be occupied by all namenode processes.
Fault Tolerance: When SNN creates a checkpoint, it copies the checkpoint to several copies of metadata. Running this operation on another machine also provides fault tolerance for distributed file systems.
Configure to run secondarynamenode on another machine

A running instance of HDFS is started through the $ hadoop_home/bin/start-dfs.sh (or start-all.sh) script on the namenode machine. This script starts the namenode process on the machine that runs the script, and the datanode process is started on the server Load balancer instance. The list of Server Load balancer instances is saved in the conf/Server Load balancer file, with one machine in one row. An SNN process will be started on another machine, which is specified by the conf/masters file.

Therefore, note that the machine specified in the conf/masters file does not mean that the jobtracker or namenode process must run on this machine, because these processes are running on launch bin/start-dfs.sh or bin/start-mapred.sh (start-all.sh) machines. Therefore, the name of the masters file is very confusing and should be called secondaries.

2. Configuration

Follow these steps:
Write all the machines that want to run the secondarynamenode process to the masters file, one row at a time.
Modify the conf/hadoop-site.xml file on the machine configured in the Masters file with the following options:

<Property> <Name>DFS. http. Address</Name> <Value>Namenode.hadoop-host.com: 50070</Value> </Property>
 

Core-site.xml: Here there are 2 parameters configurable, but in general we do not modify. FS. Checkpoint. period indicates how long the HDFS image is recorded. The default value is 1 hour. FS. Checkpoint. Size indicates the size of a record. The default value is 64 MB.

<  Property  >   <  Name  > FS. Checkpoint. Period </  Name  >   <  Value  > 3600 </  Value  >   < Description  >  The number of seconds between two periodic checkpoints.  </  Description  >   </  Property  >   <  Property  >   <  Name  > FS. Checkpoint. Size </ Name  >   <  Value  > 67108864 </  Value  >   <  Description  >  The size of the current edit log (in bytes) that triggers a periodic checkpoint even if the fs. Checkpoint. Period hasn't expired.  </  Description  >  </  Property  > 

3. Configuration check

After the configuration is complete, we need to check whether the configuration is successful. You can check the file directory on the machine that runs secondarynamenode to determine whether the configuration is successful. Enter JPs to check whether the secondarynamenode process exists. If yes, check whether there are backup records in the corresponding directory.

This directory usually exists in hadoop. tmp. DIR/dfs/namesecondary.

4. Summary

1. You can configure multiple secondarynamenode files. You can write a few more files in the master file.
2. Remember to manually copy the data to the namenode machine to restore the data. It is not automatic (see the recovery operation written above ).
3. the backup cycle can be modified. If you do not want to back up an image once an hour, you can change the backup cycle to a short time. FS. Checkpoint. period value in core-site.xml