The Standby NameNode Fails to Be Started Because It Is Not Started for a Long Time

Symptom

The standby NameNode is not started for a long time. After the edits file is automatically deleted due to the aging policy, this file cannot be found when the NameNode is restarted. As a result, an error is reported.

There appears to be a gap in the edit log. We expected txid XXX, but got txid XXX.

Procedure

1. Log in to FusionInsight Manager.
2. Choose Cluster > Services > HDFS > Configurations > All Configurations.
3. Search for and view the value of dfs.namenode.name.dir to obtain the NameNode data directory, for example, /srv/BigData/namenode/current.

   dfs.namenode.name.dir indicates the directory where DFS NameNode stores FSImages in the local file system. If this parameter is set to a list of directories separated by commas (,), FSImages are copied to all directories in the list for redundancy backup. Its default value is ${BIGDATA_DATADIR}/namenode.

4. On the HDFS service page, click the Instances tab to view and record the service IP addresses of the active and standby NameNodes.
5. Log in to the faulty standby NameNode as user root and back up the fsimage file in the data directory obtained in 3. For example, back up the data to the /srv/BigData/namenode/current.bak directory.

   mv /srv/BigData/namenode/current/ /srv/BigData/namenode/current.bak

6. Log in to the active NameNode as the root user and run the following command to copy the fsimage file to the standby NameNode:

   scp -rp /srv/BigData/namenode/current/ {IP address of the standby NameNode}:/srv/BigData/namenode/

   chown omm:wheel /srv/BigData/namenode/current -R

7. Restart the standby NameNode and check whether restart is successful. If the restart fails, contact technical support.