[
https://issues.apache.org/jira/browse/HDFS-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13446777#comment-13446777
]
Uma Maheswara Rao G commented on HDFS-3862:
-------------------------------------------
Todd, It seems like reasonable to me. I also filed one JIRA to handle this
situation with single writer HDFS-3854.
But I thought, we could simply provide a fence method which will fence the
writer, that means that we have guaranteed that no other NN can access shared
storage and then go for state change.
In fact if we are ok with leaving the fence to writer level, that is more good.
Currently also simply we have a dummy fence method, which will return true as
BK already has fencing.
>From above suggestion, adding API in JournalManager, it may require to
>creating the JournalManager for getting this info in ZKFC right?
How about simply adding one config parameter?
> QJM: don't require a fencer to be configured if shared storage has built-in
> single-writer semantics
> ---------------------------------------------------------------------------------------------------
>
> Key: HDFS-3862
> URL: https://issues.apache.org/jira/browse/HDFS-3862
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: ha
> Affects Versions: QuorumJournalManager (HDFS-3077)
> Reporter: Todd Lipcon
>
> Currently, NN HA requires that the administrator configure a fencing method
> to ensure that only a single NameNode may write to the shared storage at a
> time. Some shared edits storage implementations (like QJM) inherently enforce
> single-writer semantics at the storage level, and thus the user should not be
> forced to specify one.
> We should extend the JournalManager interface so that the HA code can operate
> without a configured fencer if the JM has such built-in fencing.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
