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 316A910692 for ; Tue, 8 Oct 2013 18:32:53 +0000 (UTC) Received: (qmail 34267 invoked by uid 500); 8 Oct 2013 18:32:50 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 34221 invoked by uid 500); 8 Oct 2013 18:32:49 -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 34203 invoked by uid 99); 8 Oct 2013 18:32:48 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Oct 2013 18:32:48 +0000 Date: Tue, 8 Oct 2013 18:32:48 +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=13789493#comment-13789493 ] Sergey Shelukhin commented on HBASE-5487: ----------------------------------------- Please let's not use coprocessors for mainline functionality... also, if we store state in system table that is hosted by master, then we don't need ZK at all, we should get rid of it. The only disadvantages from using ZK that I see are the absence getKeyBefore/After API (easy to fix by having ephemeral META table for clients to query), and having extra moving part. If we don't get rid of ZK we don't alleviate the latter so I think we should either use it for "everything" or not at all... I would prefer to use it for everything. As far as I see, ZK is more reliable than HBase RS or master, has built-in replication with faster recovery, is probably more scalable than reading from single RS, and has better model for atomic state changes. Probably has better tolerance for stuff like network partitioning too. We could do master WAL and all that stuff but I don't see a compelling reason to do this when we have a bunch of Apache code that is already written to solve all of these problems. What is the reason to not use ZK? What is the advantage of system table, or disadvantage of ZK? > 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 > Priority: Critical > Attachments: Region management in Master.pdf > > > 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 was sent by Atlassian JIRA (v6.1#6144)