SYNOPSIS

 To start:
      bin/start-balancer.sh [-threshold ]
      Example: bin/ start-balancer.sh 
                     start the balancer with a default threshold of 10%
               bin/ start-balancer.sh -threshold 5
                     start the balancer with a threshold of 5%
 To stop:
      bin/ stop-balancer.sh
 

DESCRIPTION

The threshold parameter is a fraction in the range of (0%, 100%) with a default value of 10%. The threshold sets a target for whether the cluster is balanced. A cluster is balanced if for each datanode, the utilization of the node (ratio of used space at the node to total capacity of the node) differs from the utilization of the (ratio of used space in the cluster to total capacity of the cluster) by no more than the threshold value. The smaller the threshold, the more balanced a cluster will become. It takes more time to run the balancer for small threshold values. Also for a very small threshold the cluster may not be able to reach the balanced state when applications write and delete files concurrently.

The tool moves blocks from highly utilized datanodes to poorly utilized datanodes iteratively. In each iteration a datanode moves or receives no more than the lesser of 10G bytes or the threshold fraction of its capacity. Each iteration runs no more than 20 minutes. At the end of each iteration, the balancer obtains updated datanodes information from the namenode.

A system property that limits the balancer's use of bandwidth is defined in the default configuration file:

 
   dfs.balance.bandwidthPerSec
   1048576
   Specifies the maximum bandwidth that each datanode 
 can utilize for the balancing purpose in term of the number of bytes 
 per second. 
 
 

This property determines the maximum speed at which a block will be moved from one datanode to another. The default value is 1MB/s. The higher the bandwidth, the faster a cluster can reach the balanced state, but with greater competition with application processes. If an administrator changes the value of this property in the configuration file, the change is observed when HDFS is next restarted.

MONITERING BALANCER PROGRESS

After the balancer is started, an output file name where the balancer progress will be recorded is printed on the screen. The administrator can monitor the running of the balancer by reading the output file. The output shows the balancer's status iteration by iteration. In each iteration it prints the starting time, the iteration number, the total number of bytes that have been moved in the previous iterations, the total number of bytes that are left to move in order for the cluster to be balanced, and the number of bytes that are being moved in this iteration. Normally "Bytes Already Moved" is increasing while "Bytes Left To Move" is decreasing.

Running multiple instances of the balancer in an HDFS cluster is prohibited by the tool.

The balancer automatically exits when any of the following five conditions is satisfied:

1. The cluster is balanced;
2. No block can be moved;
3. No block has been moved for five consecutive iterations;
4. An IOException occurs while communicating with the namenode;
5. Another balancer is running.

Upon exit, a balancer returns an exit code and prints one of the following messages to the output file in corresponding to the above exit reasons:

1. The cluster is balanced. Exiting
2. No block can be moved. Exiting...
3. No block has been moved for 3 iterations. Exiting...
4. Received an IO exception: failure reason. Exiting...
5. Another balancer is running. Exiting...

The administrator can interrupt the execution of the balancer at any time by running the command "stop-balancer.sh" on the machine where the balancer is running.]]> The block has at least one {@link ReplicaState#FINALIZED} replica, and is not going to be modified.]]> It has been recently allocated for write or append.]]> When a file lease expires its last block may not be {@link #COMPLETE} and needs to go through a recovery procedure, which synchronizes the existing replicas contents.]]> The client reported that all bytes are written to data-nodes with the given generation stamp and block length, but no {@link ReplicaState#FINALIZED} replicas has yet been reported by data-nodes themselves.]]> true if exclusive locks are supported or false otherwise. @throws IOException @see StorageDirectory#lock()]]> Local storage information is stored in a separate file VERSION. It contains type of the node, the storage layout version, the namespace id, and the fs state creation time.

Local storage can reside in multiple directories. Each directory should contain the same VERSION file as the others. During startup Hadoop servers (name-node and data-nodes) read their local storage information from them.

The servers hold a lock for each storage directory while they run so that other nodes were not able to startup sharing the same storage. The locks are released when the servers stop (normally or abnormally).]]> Removes contents of the current directory and creates an empty directory. This does not fully format storage directory. It cannot write the version file since it should be written last after all other storage type dependent files are written. Derived storage is responsible for setting specific storage values and writing the version file to disk. @throws IOException]]>

{@link #filesTotal}.set()]]> For the metrics that are sampled and averaged, one must specify a metrics context that does periodic update calls. Most metrics contexts do. The default Null metrics context however does NOT. So if you aren't using any other metrics context then you can turn on the viewing and averaging of sampled metrics by specifying the following two lines in the hadoop-meterics.properties file:

        dfs.class=org.apache.hadoop.metrics.spi.NullContextWithUpdateThread
        dfs.period=10
  

Note that the metrics are collected regardless of the context used. The context with the update thread is used to average the data periodically Impl details: We use a dynamic mbean that gets the list of the metrics from the metrics registry passed as an argument to the constructor]]> This class has a number of metrics variables that are publicly accessible; these variables (objects) have methods to update their values; for example:

{@link #syncs}.inc()]]> Returned to the backup node by the name-node as a reply to the {@link NamenodeProtocol#startCheckpoint(NamenodeRegistration)} request.
Contains:

• {@link CheckpointSignature} identifying the particular checkpoint
• indicator whether the backup image should be discarded before starting the checkpoint
• indicator whether the image should be transfered back to the name-node upon completion of the checkpoint.

• files with blocks that are completely missing from all datanodes.
  In this case the tool can perform one of the following actions:
  • none ({@link org.apache.hadoop.hdfs.server.namenode.NamenodeFsck#FIXING_NONE})
  • move corrupted files to /lost+found directory on DFS ({@link org.apache.hadoop.hdfs.server.namenode.NamenodeFsck#FIXING_MOVE}). Remaining data blocks are saved as a block chains, representing longest consecutive series of valid blocks.
  • delete corrupted files ({@link org.apache.hadoop.hdfs.server.namenode.NamenodeFsck#FIXING_DELETE})
• detect files with under-replicated or over-replicated blocks