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 03AF8108C3 for ; Mon, 2 Sep 2013 18:27:54 +0000 (UTC) Received: (qmail 88864 invoked by uid 500); 2 Sep 2013 18:27:53 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 88828 invoked by uid 500); 2 Sep 2013 18:27:53 -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 88804 invoked by uid 99); 2 Sep 2013 18:27:52 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Sep 2013 18:27:52 +0000 Date: Mon, 2 Sep 2013 18:27:52 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-9249) Add cp hook before setting PONR in split 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-9249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756199#comment-13756199 ] Anoop Sam John commented on HBASE-9249: --------------------------------------- bq.Here some more changes are needed for secondary index Anoop. presently not using the SplitInfo. Going through the changes what is done in HIndex. 1. Doing some ops in the before PONR hook and if that is not success don't want o continue with the split but to rollback. This can be done using bypass() on the CP? In case of bypass the core code cab throw an IOE so as to allow upper layer to do the rollback. 2. Both actual and index region got split. We would like to write to Meta both the data (daughter region entries) as one Put. For that there should be some provision provided in this beforePONR or after PONR CP hook so that that can change what is getting written to META tabl?. Do how we handle in case of batch put. We pass the WALEdit also to the hook. Hook can change it and finally core writes the resultant edit.. Same way can follow here also? > Add cp hook before setting PONR in split > ---------------------------------------- > > Key: HBASE-9249 > URL: https://issues.apache.org/jira/browse/HBASE-9249 > Project: HBase > Issue Type: Sub-task > Reporter: rajeshbabu > Assignee: rajeshbabu > Attachments: HBASE-9249.patch, HBASE-9249_v2.patch, HBASE-9249_v3.patch, HBASE-9249_v4.patch > > > This hook helps to perform split on user region and corresponding index region such that both will be split or none. > With this hook split for user and index region as follows > user region > =========== > 1) Create splitting znode for user region split > 2) Close parent user region > 3) split user region storefiles > 4) instantiate child regions of user region > Through the new hook we can call index region transitions as below > index region > =========== > 5) Create splitting znode for index region split > 6) Close parent index region > 7) Split storefiles of index region > 8) instantiate child regions of the index region > If any failures in 5,6,7,8 rollback the steps and return null, on null return throw exception to rollback for 1,2,3,4 > 9) set PONR > 10) do batch put of offline and split entries for user and index regions > index region > ============ > 11) open daughers of index regions and transition znode to split. This step we will do through preSplitAfterPONR hook. Opening index regions before opening user regions helps to avoid put failures if there is colocation mismatch(this can happen if user regions opening completed but index regions opening in progress) > user region > =========== > 12) open daughers of user regions and transition znode to split. > Even if region server crashes also at the end both user and index regions will be split or none -- 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