Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <4603173.51531291947901018.JavaMail.jira@thor>
Date: Thu, 9 Dec 2010 21:25:01 -0500 (EST)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Subject: [jira] Commented: (HBASE-3329) HLog splitting after RS/cluster
 death should directly create HFiles
In-Reply-To: <12966144.51281291947060930.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Todd Lipcon commented on HBASE-3329:
------------------------------------

I was thinking about this a bit, but we have to be cognizant of memory usage on the master. In order to limit master memory usage during splitting, we may need to "spill" the reassembled edits multiple times, which would end up creating several potentially small storefiles. This is probably not the worst thing, assuming our compaction heuristics are good, but something to be wary of.

> HLog splitting after RS/cluster death should directly create HFiles
> -------------------------------------------------------------------
>
>                 Key: HBASE-3329
>                 URL: https://issues.apache.org/jira/browse/HBASE-3329
>             Project: HBase
>          Issue Type: Bug
>          Components: regionserver
>            Reporter: Karthik Ranganathan
>
> After a RS dies or the cluster goes down and we are recovering, we first split HLogs into the logs for the regions. Then the region servers that host the regions replay the logs and open the regions.
> This can be made more efficient by directly creating HFiles from the HLogs (instead of producing a split HLogs file).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.