Return-Path: Delivered-To: apmail-hadoop-hbase-dev-archive@minotaur.apache.org Received: (qmail 62164 invoked from network); 9 Jul 2009 19:00:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jul 2009 19:00:28 -0000 Received: (qmail 94264 invoked by uid 500); 9 Jul 2009 19:00:38 -0000 Delivered-To: apmail-hadoop-hbase-dev-archive@hadoop.apache.org Received: (qmail 94215 invoked by uid 500); 9 Jul 2009 19:00:37 -0000 Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: hbase-dev@hadoop.apache.org Delivered-To: mailing list hbase-dev@hadoop.apache.org Received: (qmail 94205 invoked by uid 99); 9 Jul 2009 19:00:37 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 19:00:37 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 19:00:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 70F7529A0011 for ; Thu, 9 Jul 2009 12:00:15 -0700 (PDT) Message-ID: <1752770561.1247166015451.JavaMail.jira@brutus> Date: Thu, 9 Jul 2009 12:00:15 -0700 (PDT) From: "stack (JIRA)" To: hbase-dev@hadoop.apache.org Subject: [jira] Commented: (HBASE-1551) HBase should manage multiple node ZooKeeper quorum In-Reply-To: <885609800.1245444487500.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HBASE-1551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729383#action_12729383 ] stack commented on HBASE-1551: ------------------------------ Go ahead commit Nitay. We can file issues with it as we find them. I don't have resources to hand to test this at mo. > HBase should manage multiple node ZooKeeper quorum > -------------------------------------------------- > > Key: HBASE-1551 > URL: https://issues.apache.org/jira/browse/HBASE-1551 > Project: Hadoop HBase > Issue Type: Improvement > Reporter: Nitay Joffe > Assignee: Nitay Joffe > Fix For: 0.20.0 > > Attachments: hbase-1551-v2.patch, hbase-1551.patch > > > I thought there was already a JIRA for this, but I cannot seem to find it. > We need to manage multiple node ZooKeeper quorums (required for fully distributed option) in HBase to make things easier for users. > Here's relevant IRC conversation with Ryan and Andrew: > {code} > Jun 17 18:14:39 right now we include our client deps in hbase/lib > Jun 17 18:14:47 so removing zookeeper would be problematic > Jun 17 18:14:56 but hbase does put up a private zk quorum > Jun 17 18:15:02 it just doesnt bother with q>1 > Jun 17 18:15:05 dj_ryan, nitay: agreed, so that's why i wonder about a private zk quorum managed by hbase > Jun 17 18:15:12 q ~= 5 > Jun 17 18:15:22 so maybe we should ship tools to manage it > Jun 17 18:15:23 if possible > Jun 17 18:15:29 i can agree with that > Jun 17 18:15:39 apurtell, ok, i'd be happy to bump the priority of hbase managing full cluster and work on that > Jun 17 18:15:47 * iand (n=iand@205.158.58.226.ptr.us.xo.net) has joined #hbase > Jun 17 18:15:48 nitay: that would be awesome > Jun 17 18:15:57 then i can skip discussions with cloudera about including zk also > Jun 17 18:16:12 and we can use some private ports that won't conflict with a typical zk install > Jun 17 18:16:15 but i also think that users should be able to point at existing clusters, so as long as your rpms are compatible, it should be fine > Jun 17 18:16:23 apurtell, isn't hadoop going to start using ZK > Jun 17 18:16:31 nitay: agree, but this is the cloudera-autoconfig-rpm (and deb) case > Jun 17 18:16:34 the cloudera dude was working on using it for namenode whatnot like we do for master > Jun 17 18:16:35 so there are only 2 things > Jun 17 18:16:38 - set up myids > Jun 17 18:16:38 what are they doing for that > Jun 17 18:16:40 - start zk > Jun 17 18:16:42 - stop zk > Jun 17 18:16:50 we dont want to start/stop zk just when we are doing a cluster bounce > Jun 17 18:16:51 ye stupid myids > Jun 17 18:16:52 you start it once > Jun 17 18:16:54 and be done with ti > Jun 17 18:16:58 * iand (n=iand@205.158.58.226.ptr.us.xo.net) has left #hbase ("Leaving.") > Jun 17 18:17:13 dj_ryan: yes, start it once. that's what i do. works fine through many hbase restarts... > Jun 17 18:17:28 so then we need a separate shell cmd or something to stop zk > Jun 17 18:17:35 and start on start-hbase if not already running type thing > Jun 17 18:17:43 yes > Jun 17 18:17:58 ok > Jun 17 18:18:19 with quorum peers started on nodes in conf/regionservers, up to ~5 if possible > Jun 17 18:18:37 but what about zoo.cfg? > Jun 17 18:18:51 oh i was thinking of having separate conf/zookeepers > Jun 17 18:18:58 nitay: even better > Jun 17 18:18:59 but we can use first five RS too > Jun 17 18:19:26 apurtell, yeah so really there wouldnt be a conf/zookeepers, i would rip out hostnames from zoo.cfg > Jun 17 18:19:38 or go the other way, generate zoo.cfg from conf/zookeepers > Jun 17 18:19:42 gotta do one or the other > Jun 17 18:19:49 dont want to have to edit both > Jun 17 18:19:54 nitay: right > Jun 17 18:20:21 well... > Jun 17 18:20:29 zoo.cfg has the right info right now, cause u need things other than just hostnames, i.e. client and quorum ports > Jun 17 18:20:31 we can leave out servers from our default zoo.cfg > Jun 17 18:20:39 and consider a conf/zookeepers > Jun 17 18:20:47 i call it conf/zoos > Jun 17 18:20:54 in my zookeeper config > Jun 17 18:20:54 dir > Jun 17 18:20:57 and then have our parsing of zoo.cfg insert them > Jun 17 18:21:08 cause right now its all off java Properties anyways > Jun 17 18:21:12 and let the zk wrapper parse the files if they exist and otherwise build the list of quorum peers like it does already > Jun 17 18:21:34 so someone could edit either and it would dtrt > Jun 17 18:21:48 apurtell, yeah, makes sense > Jun 17 18:21:58 we can discuss getting rid of zoo.cfg completely > Jun 17 18:22:12 put it all in XML and just create a Properties for ZK off the right props > Jun 17 18:22:14 for my purposes, i just need some files available for a post install script to lay down a static hbase cluster config based on what it discovers about the hadoop installation > Jun 17 18:23:56 then i need to hook sysvinit and use chkconfig to enable/disable services on the cluster nodes according to their roles defined by hadoop/conf/masters and hadoop/conf/regionservers > Jun 17 18:24:13 so we put the hmaster on the namenode > Jun 17 18:24:17 and the region servers on the datanodes > Jun 17 18:24:35 hadoop/conf/slaves i mean > Jun 17 18:24:44 and pick N hosts out of slaves to host the zk quorum > Jun 17 18:24:50 make sense? > Jun 17 18:25:33 yes i think so, and u'll be auto generating the hbase configs for what servers run what then? > Jun 17 18:25:50 nitay: yes > Jun 17 18:25:51 which is why a simple line by line conf/zookeepers type file is clean and easy > Jun 17 18:25:57 nitay: agree > Jun 17 18:25:59 so i think my initial question has been answered, hbase will manage a private zk ensemble > Jun 17 18:26:07 ... somehow > Jun 17 18:26:10 right :) > Jun 17 18:26:15 ok, thanks > {code} -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.