hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron T. Myers (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-1974) HA: Introduce active and standby states to the namenode
Date Mon, 08 Aug 2011 19:40:27 GMT

    [ https://issues.apache.org/jira/browse/HDFS-1974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081152#comment-13081152
] 

Aaron T. Myers commented on HDFS-1974:
--------------------------------------

Thanks for posting this design doc, Suresh. Some comments on the latest patch:

# {{public static boolean isHAEnabled(Configuration conf)}} - is the intention that this will
return true if HA is enabled on the cluster? Or that this will return true only on the currently-active
NN? The answer to this question may invalidate the next question.
# {{this.state = DFSUtil.isHAEnabled(conf) ? ACTIVE_STATE : STANDBY_STATE;}} - should probably
be replaced with a TODO. It's obviously not reasonable to have both NNs start as active just
because HA is enabled. There needs to be some leader determination.
# In {{HAState}}, why not make {{enterState}} and {{exitState}} abstract?
# I find it unfortunate/brittle that every FS operation call in {{NameNode}} now has to include
the method name as a string, particularly since this is only used for logging. Is the stack
trace, which will include the method name, not sufficient?
# {{UnsupportedActionException}} seems redundant with {{o.a.h.ipc.StandbyException}}.
# In {{NameNode.OperationCategory}}, the comments are identical for {{CHECKPOINT}} and {{JOURNAL}}
operations. For that matter, I'm not sure which operations are intended to fall under {{JOURNAL}}.
# {{StandbyState.checkOperation}} for the time being, it doesn't make sense that we should
be serving reads from the standby. We don't yet have any guarantees about the freshness of
the standby's date. Let's leave that for a later optimization.
# I don't understand the purpose of having both {{HAState.setState}} and {{HAState.(standbyToActive|activeToStandby)}}.
Shouldn't just {{setState}} be sufficient?
# In {{HAState.setState}}, you have {{exitState(nn); s.enterState(nn);}}. What state should
the NN be considered to be in between these calls?
# You never reassign the value of {{NameNode.state}}.
# There's no synchronization in this patch. Many or most of these operations will need some
locking.
# It seems like all of the new classes should go in the {{o.a.h.hdfs.server.namenode.ha}}
package, rather than just {{o.a.h.hdfs.server.namenode}}.

> HA: Introduce active and standby states to the namenode
> -------------------------------------------------------
>
>                 Key: HDFS-1974
>                 URL: https://issues.apache.org/jira/browse/HDFS-1974
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: name-node
>            Reporter: Suresh Srinivas
>            Assignee: Suresh Srinivas
>         Attachments: HDFS-1974.1.patch, HDFS-1974.2.patch, HDFS-1974.patch
>
>
> Currently namenode supports active, secondary and backup roles. To support namenode high
availability, active and standby states are needed. Note that this is different from the existing
notion of namenode role, where a namenode cannot transition from one role to the other.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message