Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 16 May 2014 11:22:50 +0000 (UTC)
From: "Francis Liu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12696009.1392829216561.366422.1400239370026@arcas>
In-Reply-To: <JIRA.12696009.1392829216561@arcas>
References: <JIRA.12696009.1392829216561@arcas>
Subject: [jira] [Commented] (HBASE-10569) Co-locate meta and master
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Francis Liu commented on HBASE-10569:
-------------------------------------

{quote}
I think the main motivation is the colocation of all the components that are usually involved in a single "transaction". The 
main example of this is the Assignment, which involve: Master, META, ZooKeeper.
{quote}
I see but the notion of consolidation is counter-intuitive if we want hbase to be horizontally scalable. See the-node-that-must-not-be-named as an example.

{quote}
#1 and #2 are part of a generic notification system, which will be used to propagate ACLs, Visibility, Quotas. (In theory the base of this system is also the one behind the ZK-less Assignment)
{quote}
We should be able to implement a notification system without #1 and #2? Would be good to have a doc describing and motivatiing why we need the dependency. And why it is better than a generic version of the current approach.

{quote}
For the Horizontal scalability, I think that we are going to have Multiple Master each one operating on its subsection of "meta" (and the notification system). This means that you will have concurrent assignments on different masters.
The best case is where you can fit a full table (regions metadata) on a single master, the other case is where your table is split on multiple master which means that operation that requires to work on the full set of regions e.g. delete, disable, enable need some sort of coordination to provide the full consistency that you'll get with a full table that fits on a single master.
{quote}
Yep, instead avoiding distributed coordination tasks we should make distributed operations a first class operation.


> Co-locate meta and master
> -------------------------
>
>                 Key: HBASE-10569
>                 URL: https://issues.apache.org/jira/browse/HBASE-10569
>             Project: HBase
>          Issue Type: Improvement
>          Components: master, Region Assignment
>            Reporter: Jimmy Xiang
>            Assignee: Jimmy Xiang
>             Fix For: 0.99.0
>
>         Attachments: Co-locateMetaAndMasterHBASE-10569.pdf, hbase-10569_v1.patch, hbase-10569_v2.patch, hbase-10569_v3.1.patch, hbase-10569_v3.patch, master_rs.pdf
>
>
> I was thinking simplifying/improving the region assignments. The first step is to co-locate the meta and the master as many people agreed on HBASE-5487.


--
This message was sent by Atlassian JIRA
(v6.2#6252)