[
https://issues.apache.org/jira/browse/HDFS-6203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963476#comment-13963476
]
Jing Zhao commented on HDFS-6203:
---------------------------------
Currently if users enable the automatic failover, the manual transitionToActive
operation is disallowed, unless a "forcemanual" option is given and the user
confirms the operation. Also the prompt msg states the risk of the operation.
Do you mean we should also do this for non-automatic failover case?
For checking other NN's state, if we add the check into the transitionToActive
method, we cannot still guarantee that the other NN will not transition to
active after the checking. Thus I think the checking here will not be very
useful.
> check other namenode's state before HAadmin transitionToActive
> --------------------------------------------------------------
>
> Key: HDFS-6203
> URL: https://issues.apache.org/jira/browse/HDFS-6203
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: ha
> Affects Versions: 2.3.0
> Reporter: patrick white
>
> Current behavior is that the HAadmin -transitionToActive command will
> complete the transition to Active even if the other namenode is already in
> Active state. This is not an allowed condition and should be handled by
> fencing, however setting both namenode's active can happen accidentally with
> relative ease, especially in a production environment when performing manual
> maintenance operations.
> If this situation does occur it is very serious and will likely cause data
> loss, or best case, require a difficult recovery to avoid data loss.
> This is requesting an enhancement to haadmin's -transitionToActive command,
> to have HAadmin check the Active state of the other namenode before
> completing the transition. If the other namenode is Active, then fail the
> request due to other nn already-active.
> Not sure if there is a scenario where both namenode's being Active is valid
> or desired, but to maintain functional compatibility a 'force' parameter
> could be added to override this check and allow previous behavior.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
