[
https://issues.apache.org/jira/browse/HDFS-14067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16685870#comment-16685870
]
Chao Sun commented on HDFS-14067:
---------------------------------
Thanks for the clarification [~xkrogen]. I think the check was introduced
HADOOP-8247, and the reason was because if we allow manual and auto failover at
the same time, the state tracked by ZK could be inconsistent with the actual
state. For instance, in a HA cluster with 1 active and 1 standby, potentially
one could manually transition the state of the NNs and swap their roles, but
the ZK will still track the old state.
In our case, I do see some potential inconsistency. Currently the
ZKFailoverController only tracks active and standby state. And, if we manually
transition a standby to observer, ZK will still keep the old state and even
make the observer eligible for election, which is incorrect. This somewhat
overlaps with HDFS-13182.
> Allow manual failover between standby and observer
> --------------------------------------------------
>
> Key: HDFS-14067
> URL: https://issues.apache.org/jira/browse/HDFS-14067
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Chao Sun
> Assignee: Chao Sun
> Priority: Major
> Attachments: HDFS-14067-HDFS-12943.000.patch
>
>
> Currently if automatic failover is enabled in a HA environment, transition
> from standby to observer would be blocked:
> {code}
> [hdfs@*** hadoop-3.3.0-SNAPSHOT]$ bin/hdfs haadmin -transitionToObserver ha2
> Automatic failover is enabled for NameNode at ****
> Refusing to manually manage HA state, since it may cause
> a split-brain scenario or other incorrect state.
> If you are very sure you know what you are doing, please
> specify the --forcemanual flag.
> {code}
> We should allow manual transition between standby and observer in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
