[ 
https://issues.apache.org/jira/browse/HDFS-12499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bharat Viswanadham updated HDFS-12499:
--------------------------------------
    Description: 
HDFS + Federation cluster +QJM

dfs.shared.edits.dir property can be set as
1. dfs.shared.edits.dir.<<nameserviceId>> 
2. dfs.shared.edits.dir.<<nameserviceId>> .<<namenodId>>

Configuring both ways are supported currently. Option 2 should not be 
supported, as for a particular nameservice quoram of journal nodes should be 
same.

If option 2 is supported, users can configure for a nameservice Id which is 
having two namenodes, they can configure different values for journal nodes. 
which is incorrect.

Example:
<property>
    <name>dfs.namenode.shared.edits.dir.ns1.nn1</name>
    
<value>qjournal://mycluster-node-1:8485;mycluster-node-2:8485;mycluster-node-3:8485/ns1</value>
  </property>
<property>
    <name>dfs.namenode.shared.edits.dir.ns1.nn1</name>
    
<value>qjournal://mycluster-node-3:8485;mycluster-node-4:8485;mycluster-node-5:8485/ns1</value>
  </property>
  <property>
    <name>dfs.namenode.shared.edits.dir.ns2.nn1</name>
    
<value>qjournal://mycluster-node-1:8485;mycluster-node-2:8485;mycluster-node-3:8485/ns2</value>
  </property>
  <property>
    <name>dfs.namenode.shared.edits.dir.ns2.nn1</name>
    
<value>qjournal://mycluster-node-3:8485;mycluster-node-4:8485;mycluster-node-5:8485/ns2</value>
  </property>

This jira is to discuss do we need to support 2nd option way of configuring or 
remove it?


  was:
HDFS + Federation cluster +QJM

dfs.shared.edits.dir property can be set as
1. dfs.shared.edits.dir.<<nameserviceId>> 
2. dfs.shared.edits.dir.<<nameserviceId>> .<<namenodId>>

Configuring both ways are supported currently. Option 2 should not be 
supported, as for a particular nameservice quoram of journal nodes should be 
same.

This jira is to discuss do we need to support 2nd option way of configuring or 
remove it?



> dfs.namenode.shared.edits.dir property is currently namenode specific key
> -------------------------------------------------------------------------
>
>                 Key: HDFS-12499
>                 URL: https://issues.apache.org/jira/browse/HDFS-12499
>             Project: Hadoop HDFS
>          Issue Type: Bug
>            Reporter: Bharat Viswanadham
>            Assignee: Bharat Viswanadham
>              Labels: Incompatible
>
> HDFS + Federation cluster +QJM
> dfs.shared.edits.dir property can be set as
> 1. dfs.shared.edits.dir.<<nameserviceId>> 
> 2. dfs.shared.edits.dir.<<nameserviceId>> .<<namenodId>>
> Configuring both ways are supported currently. Option 2 should not be 
> supported, as for a particular nameservice quoram of journal nodes should be 
> same.
> If option 2 is supported, users can configure for a nameservice Id which is 
> having two namenodes, they can configure different values for journal nodes. 
> which is incorrect.
> Example:
> <property>
>     <name>dfs.namenode.shared.edits.dir.ns1.nn1</name>
>     
> <value>qjournal://mycluster-node-1:8485;mycluster-node-2:8485;mycluster-node-3:8485/ns1</value>
>   </property>
> <property>
>     <name>dfs.namenode.shared.edits.dir.ns1.nn1</name>
>     
> <value>qjournal://mycluster-node-3:8485;mycluster-node-4:8485;mycluster-node-5:8485/ns1</value>
>   </property>
>   <property>
>     <name>dfs.namenode.shared.edits.dir.ns2.nn1</name>
>     
> <value>qjournal://mycluster-node-1:8485;mycluster-node-2:8485;mycluster-node-3:8485/ns2</value>
>   </property>
>   <property>
>     <name>dfs.namenode.shared.edits.dir.ns2.nn1</name>
>     
> <value>qjournal://mycluster-node-3:8485;mycluster-node-4:8485;mycluster-node-5:8485/ns2</value>
>   </property>
> This jira is to discuss do we need to support 2nd option way of configuring 
> or remove it?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org

Reply via email to