[ https://issues.apache.org/jira/browse/HDFS-6005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Suresh Srinivas updated HDFS-6005: ---------------------------------- Attachment: HDFS-6005.03.patch Thanks for the comments [~arpitagarwal]. New patches addresses them. > Simplify Datanode rollback and downgrade > ---------------------------------------- > > Key: HDFS-6005 > URL: https://issues.apache.org/jira/browse/HDFS-6005 > Project: Hadoop HDFS > Issue Type: Sub-task > Components: datanode, namenode > Reporter: Suresh Srinivas > Assignee: Suresh Srinivas > Attachments: HDFS-6005.01.patch, HDFS-6005.02.patch, > HDFS-6005.03.patch, HDFS-6005.patch > > > Problem: > When rolling upgrade fails, the cluster can either be downgraded or rolled > back. With the current functionality in this feature branch, it is possible > to downgrade namenode, while datanode is incorrectly rolled back. This does > not affect the cluster state. The old blocks that appear back on the datanode > due to rollback will be deleted. Similarly it is also possible to rollback > namenode, while datanode is not rolled back. This can cause problem where old > blocks do not appear back on the datanode and can result in missing blocks. > Solution: > I propose making the following changes: > During rollback or downgrade, the entire cluster must be restarted. The > datanodes always restore the deleted blocks on restart and go back to trash > disabled mode. There is no need for datanodes to be started up > -rollingUpgrade -rollback, anymore. > # On namenode downgrade, the restored blocks are deleted. > # On namenode rollback, the restored blocks will be retained and any newly > created blocks (since the start of rolling upgrade) are deleted. > This is much simpler operationally and solves the problem described above. -- This message was sent by Atlassian JIRA (v6.1.5#6160)