[
https://issues.apache.org/jira/browse/HDFS-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13863927#comment-13863927
]
Suresh Srinivas edited comment on HDFS-5138 at 1/7/14 5:46 AM:
---------------------------------------------------------------
This jira can use a design document. The current description in the comment
covers "what is being done", but it is not clear "why it is being done that
way". The subtle issues may be understood better with a design document. I
would love to see a separate summary section that covers how commands worked
before and how they work now and what commands are no longer supported.
Some early comments:
bq. I've removed the "-finalize" startup option, and instead running with this
will direct users to use the `hdfs dfsadmin -finalizeUpgrade' command.
Supporting both styles of finalization seems unnecessary, and makes HA
finalization more difficult.
Can you describe what is the difference between this vs older version of
finalize? The command -finalize is fairly well know and this change will be
backward compatible.
bq. Starting the NN with the '-rollback' flag will perform the rollback just as
before, but it will not then proceed to start the NN daemon. Supporting this
mode also makes HA rollback more difficult, and doesn't seem to be necessary or
helpful, since to perform a rollback we don't need to load the fsimage/edit
log, and thus performing the actual rollback should be quick. Operators can
then start the NN as normal after rolling back the FS.
Sorry I am not sure I understand this. Why does HA rollback become more
difficult?
bq. On start, each one of the NNs will first try to create a special lock file,
either in the shared edits dir in the NFS case or on each of the JNs in the QJM
case. This lock file will contain the CTime that that NN would like to upgrade
the...
Why is the lock file required? Why cannot NN just write an editlog about
upgrade intent, including the new layout version? During rollback we can
discount the editlog starting from the upgrade intent log. Infact we can also
consider requiring users to save namespace with empty editlogs? With this,
perhaps we can avoid the following:
bq. At the time when either NN is transitioned to the active state, that NN
will perform an upgrade of the shared log, either on NFS or on the JNs.
bq. To finalize an HA upgrade, an operator will just use hdfsadmin as described
before. The active NN at the time this happens will perform the upgrade of the
shared log. Finalization will also remove the shared log lock file previously
described.
You mean finalize of the shared log in above?
was (Author: sureshms):
This jira can use a design document. The current description in the comment
covers "what is being done", but it is not clear "why it is being done that
way". The subtle issues may be understood better with a design document. I
would love to see a separate summary section that covers how commands worked
before and how they work now and what commands are no longer supported.
Some early comments:
bq. I've removed the "-finalize" startup option, and instead running with this
will direct users to use the `hdfs dfsadmin -finalizeUpgrade' command.
Supporting both styles of finalization seems unnecessary, and makes HA
finalization more difficult.
Can you describe what is the difference between this vs older version of
finalize? The command -finalize is fairly well know and this change will be
backward compatible.
bq. Starting the NN with the '-rollback' flag will perform the rollback just as
before, but it will not then proceed to start the NN daemon. Supporting this
mode also makes HA rollback more difficult, and doesn't seem to be necessary or
helpful, since to perform a rollback we don't need to load the fsimage/edit
log, and thus performing the actual rollback should be quick. Operators can
then start the NN as normal after rolling back the FS.
Sorry I am not sure I understand this. Why does HA rollback become more
difficult?
bq. On start, each one of the NNs will first try to create a special lock file,
either in the shared edits dir in the NFS case or on each of the JNs in the QJM
case. This lock file will contain the CTime that that NN would like to upgrade
the...
Why is the lock file required? Why cannot NN just write an editlog about
upgrade intent, including the new layout version? During rollback we can
discount the editlog starting from the upgrade intent log. Infact we can also
consider requiring users to save namespace with empty editlogs? With this,
perhaps we can avoid the following:
bq. At the time when either NN is transitioned to the active state, that NN
will perform an upgrade of the shared log, either on NFS or on the JNs.
bq. To finalize an HA upgrade, an operator will just use hdfsadmin as described
before. The active NN at the time this happens will perform the upgrade of the
shared log. Finalization will also remove the shared log lock file previously
described.
You mean finalize of the share log in above?
> Support HDFS upgrade in HA
> --------------------------
>
> Key: HDFS-5138
> URL: https://issues.apache.org/jira/browse/HDFS-5138
> Project: Hadoop HDFS
> Issue Type: Bug
> Affects Versions: 2.1.1-beta
> Reporter: Kihwal Lee
> Assignee: Aaron T. Myers
> Priority: Blocker
> Attachments: HDFS-5138.patch, HDFS-5138.patch, HDFS-5138.patch
>
>
> With HA enabled, NN wo't start with "-upgrade". Since there has been a layout
> version change between 2.0.x and 2.1.x, starting NN in upgrade mode was
> necessary when deploying 2.1.x to an existing 2.0.x cluster. But the only way
> to get around this was to disable HA and upgrade.
> The NN and the cluster cannot be flipped back to HA until the upgrade is
> finalized. If HA is disabled only on NN for layout upgrade and HA is turned
> back on without involving DNs, things will work, but finaliizeUpgrade won't
> work (the NN is in HA and it cannot be in upgrade mode) and DN's upgrade
> snapshots won't get removed.
> We will need a different ways of doing layout upgrade and upgrade snapshot.
> I am marking this as a 2.1.1-beta blocker based on feedback from others. If
> there is a reasonable workaround that does not increase maintenance window
> greatly, we can lower its priority from blocker to critical.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
