Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 89FB2EE41 for ; Wed, 16 Jan 2013 03:26:15 +0000 (UTC) Received: (qmail 62095 invoked by uid 500); 16 Jan 2013 03:26:14 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 61836 invoked by uid 500); 16 Jan 2013 03:26:14 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 61789 invoked by uid 99); 16 Jan 2013 03:26:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Jan 2013 03:26:13 +0000 Date: Wed, 16 Jan 2013 03:26:13 +0000 (UTC) From: "Sergey Shelukhin (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-5487) Generic framework for Master-coordinated tasks MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-5487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13554704#comment-13554704 ] Sergey Shelukhin commented on HBASE-5487: ----------------------------------------- My main point is that currently two external region states in ZK and a table, plus two complex internal states in server and master, are a root of some non-trivial part of all evil. Especially the nature of ZK state, that comes and goes. Imho we should remove one of them from being actively managed. ZK has notifications and seems better suited for locking/atomic updates; w.r.t. availability it has no disadvantage since everything (e.g. locating the root) fails without ZK anyway, even if we do remove state machines from there. System tables are more native to HBase and have built-in WAL, plus have advantages for recovery. Maybe instead of WAL we can use ZK as universal source of region state (w/o assorted transient nodes e.g. one node per region that is always there, or maybe two if we want to use lock with lease to unassign) and mirror it to system table that is only used for recovery like you describe, or when ZK state disappears? Otherwise I think we should just use system table as universal source of region state and get rid of ZK region state. With one source of truth master and server logic can probably be dumber. > Generic framework for Master-coordinated tasks > ---------------------------------------------- > > Key: HBASE-5487 > URL: https://issues.apache.org/jira/browse/HBASE-5487 > Project: HBase > Issue Type: New Feature > Components: master, regionserver, Zookeeper > Affects Versions: 0.94.0 > Reporter: Mubarak Seyed > Assignee: Nick Dimiduk > > Need a framework to execute master-coordinated tasks in a fault-tolerant manner. > Master-coordinated tasks such as online-scheme change and delete-range (deleting region(s) based on start/end key) can make use of this framework. > The advantages of framework are > 1. Eliminate repeated code in Master, ZooKeeper tracker and Region-server for master-coordinated tasks > 2. Ability to abstract the common functions across Master -> ZK and RS -> ZK > 3. Easy to plugin new master-coordinated tasks without adding code to core components -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira