Decommissioning a Datanode in a Hadoop cluster

Sometimes we may require to remove a node from a hadoop cluster without loosing the data.
For this we have to do the decommissioning procedures.
Decommisioning will exclude a node from the cluster after replicating the data present in the decommissioning node to the other active nodes.

The decommissioning is very simple. The steps are explained below.
First stop the tasktracker in the node to be decommissioned.
In the namenode machine add the below property to the hdfs-site.xml


where dfs.exclude is a file that we have to create and place it in a safe location. Better to keep it in HADOOP_CONF_DIR (/etc/hadoop/conf).

Create a file named dfs.exclude and add the hostnames of machines that need to be decommissioned line by line.

Eg: dfs.exclude


After doing this, execute the following command from the superuser in the namenode machine.

hadoop dfsadmin -refreshNodes

After this, check the namenode UI. ie http://namenode:50070
You will be able to see the machines under decommissioning nodes.
The decommissioning process will take some time.
After the re-replication gets completed, the machine will be added to decommissioned nodes list.
After this, the decommissioned node can be safely removed from the cluster. 🙂

Deployment and Management of Hadoop Clusters

Upgrading Hadoop Clusters

Last day me and my friends tried hadoop cluster upgrade.

We tried two upgrades and both were successful.

One was from cdh3u1 cluster to cdh-4.3.0 and other from cdh 4.1.2 to cdh 4.3.0.
For upgrading we need to upgrade the hadoop installation and the filesystem.
It was a nice experience.

The steps we followed are listed below.

First we checked the filesystem for missing blocks and created the report of the entire filesystem.

From the superuser (hdfs), we executed the command

hadoop dfsadmin –report  > reportold.log

hadoop  fsck  / >  fsckold.log

With this we will get the reports and status of the entire filesystem.

We can keep these for future comparison.

If there are any issues found in the report, do the necessary actions for making it proper.

If everything is fine, we can move futher with our upgrade process.

After this  we stopped all the processes.

For ensuring no accidental data loss, we backed up our namenode and datanode storage.

ie and

After that we copied the hadoop configuration files and saved it in a different location for further use.

Then we uninstalled the entire hadoop installation(old version).

Care should be taken for keeping the contents of, secure.

We created a CDH 4.3.0 local repository and installed CDH 4.3.0 in all the machines similar to old version. The installation steps are mentioned in my previous posts.

Creating A Local YUM Repository

Hadoop Installation

Then we added the configuration files which we copied from the older installation previously.

We pointed the and to the correct locations.

After doing this, in the namenode machine, execute the following command.

/etc/init.d/hadoop-hdfs-namenode upgrade


service hadoop-hdfs-namenode upgrade

This This will start the namenode and will upgrade the hadoop filesystem to the newer version.

After this, start all the other daemons and check whether everything is working fine or not.

Check the filesystem using the below commands (execute these commands from superuser)

hadoop dfsadmin –report  > reportnew.log

hadoop  fsck  /  >  fscknew.log

Compare the reportnew.log , fscknew.log with reportold.log and fsckold.log.

Note: If we are not satisfied with the upgrade, we can rollback to the previous version. This can be done by uninstalling the newer version and installing the older version  and execting the command

/etc/init.d/hadoop-hdfs-namenode rollback

This can be done only once and cannot do once the upgrade is finalized

If both the reports are same and if there is no problem of missing blocks, we can finalize our upgrade.

Stop all the daemons and execute the following command in the namenode machine

/etc/init.d/hadoop-hdfs-namenode finalizeUpgrade

Once the upgrade is finalized, we cannot rollback.

Note: From our experience we found that cdh4.1.2 filesystem and cdh4.3.0 filesystem are compatable. ie we found cdh-4.3.0 working properly by using the cdh4.1.2’s filesystem without executing the upgrade command.