[jira] Issue Comment Edited: (HBASE-1145) Ensure that there is only 1 Master with Zookeeper

["Nitay Joffe (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/HBASE-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669305#action_12669305 ] 

nitay edited comment on HBASE-1145 at 1/31/09 4:54 PM:
-------------------------------------------------------------

There is a bit of an issue regarding getting rid of the "hbase.master" property in hbase-site.xml. Currently, anybody in HBase needing ZooKeeper parses the server.X lines out of conf/zoo.cfg to know how to connect to ZooKeeper. If there are no server.X lines, it means we are running a single instance ZooKeeper on the master server. To find that server, we use the "hbase.master" property in hbase-site.xml.

After discussing it with Andrew Purtell and Michael Stack, we came up with the following:

We have three cases:
1) "local" mode. All servers/clients are on localhost.
2) Distributed operation with single instance ZooKeeper running on master host.
3) Distributed operation with distributed ZooKeeper running.

To fix these cases (1 and 2) and allow us to remove the "master.host" property from hbase-site.xml, we need to make sure there is _always_ a server.X line with the master's address in the zoo.cfg. Even when you're running a single instance ZooKeeper on the master server, there should be a single server.X line with the master's address.

To avoid adding a lot of configuration headache on the user, we want to have the default conf/zoo.cfg have a sensible default for the single server master hostname case. We suggest shipping a new ZooKeeper jar with ZOOKEEPER-279 patched in, and using the variable substitution to inject the master hostname into zoo.cfg. For example, our new zoo.cfg would look something like:


<code>
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
dataDir=${hbase.tmp.dir}/zookeeper
# the port at which the clients will connect
clientPort=2181 

server.0=${master.address.hostname}:2888:3888
</code>


The "master.address.hostname" is a new property being added to the hbase-site.xml during this period while we transition users to ZooKeeper. If the property is not set, we will use gethostname() to fill in the variable and produce copious warning messages that it may not work and the user should either fill in that variable in hbase-site.xml, or edit zoo.cfg by hand.

We also think that we should make HBase capable of managing a distributed ZooKeeper service sooner rather than later.

      was (Author: nitay):
    There is a bit of an issue regarding getting rid of the "hbase.master" property in hbase-site.xml. Currently, anybody in HBase needing ZooKeeper parses the server.X lines out of conf/zoo.cfg to know how to connect to ZooKeeper. If there are no server.X lines, it means we are running a single instance ZooKeeper on the master server. To find that server, we use the "hbase.master" property in hbase-site.xml.

After discussing it with Andrew Purtell and Michael Stack, we came up with the following:

We have three cases:
1) "local" mode. All servers/clients are on localhost.
2) Distributed operation with single instance ZooKeeper running on master host.
3) Distributed operation with distributed ZooKeeper running.

To fix these cases (1 and 2) and allow us to remove the "master.host" property from hbase-site.xml, we need to make sure there is _always_ a server.X line with the master's address in the zoo.cfg. Even when you're running a single instance ZooKeeper on the master server, there should be a single server.X line with the master's address.

To avoid adding a lot of configuration headache on the user, we want to have the default conf/zoo.cfg have a sensible default for the single server master hostname case. We suggest shipping a new ZooKeeper jar with ZOOKEEPER-279 patched in, and using the variable substitution to inject the master hostname into zoo.cfg. For example, our new zoo.cfg would look something like:


# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial 
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between 
# sending a request and getting an acknowledgement
syncLimit=5
# the directory where the snapshot is stored.
dataDir=${hbase.tmp.dir}/zookeeper
# the port at which the clients will connect
clientPort=2181 

server.0=${master.address.hostname}:2888:3888


The "master.address.hostname" is a new property being added to the hbase-site.xml during this period while we transition users to ZooKeeper. If the property is not set, we will use gethostname() to fill in the variable and produce copious warning messages that it may not work and the user should either fill in that variable in hbase-site.xml, or edit zoo.cfg by hand.

We also think that we should make HBase capable of managing a distributed ZooKeeper service sooner rather than later.
  
> Ensure that there is only 1 Master with Zookeeper
> -------------------------------------------------
>
>                 Key: HBASE-1145
>                 URL: https://issues.apache.org/jira/browse/HBASE-1145
>             Project: Hadoop HBase
>          Issue Type: Sub-task
>            Reporter: Jean-Daniel Cryans
>            Assignee: Nitay Joffe
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.