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

Anoop Sam John commented on HBASE-7006:
---------------------------------------

Do we need a cleaner abstraction layer for RS->RS communication?  May be later 
when we can do a HLog to region opening RS collocation (RS where the region is 
newly assigned only doing the HLog split) we can do stuff in this layer so as 
to avoid the RS connection based calls but just get the Region ref from RS and 
do direct writes)

As I mentioned in some above comment when we can do the multi WAL and if we go 
with fixed regions for a WAL (we are infact doing virtula groups of regions in 
RS), we can try(max try) assigning all regions in one group to a RS and give 
the log splitting work for those WAL to this RS then it will be 100% locality 
wrt the replay commands. Sounds sensible? May be in such a case the replay can 
create the HFiles directly avoiding the memstore write and then flushes? (Like 
the bulk loading way)  Some thoughts coming.. Pls correct me if I am going 
wrong.
                
> [MTTR] Study distributed log splitting to see how we can make it faster
> -----------------------------------------------------------------------
>
>                 Key: HBASE-7006
>                 URL: https://issues.apache.org/jira/browse/HBASE-7006
>             Project: HBase
>          Issue Type: Bug
>          Components: MTTR
>            Reporter: stack
>            Assignee: Jeffrey Zhong
>            Priority: Critical
>             Fix For: 0.95.1
>
>         Attachments: hbase-7006-combined.patch, hbase-7006-combined-v1.patch, 
> hbase-7006-combined-v3.patch, hbase-7006-combined-v4.patch, LogSplitting 
> Comparison.pdf, 
> ProposaltoimprovelogsplittingprocessregardingtoHBASE-7006-v2.pdf
>
>
> Just saw interesting issue where a cluster went down  hard and 30 nodes had 
> 1700 WALs to replay.  Replay took almost an hour.  It looks like it could run 
> faster that much of the time is spent zk'ing and nn'ing.
> Putting in 0.96 so it gets a look at least.  Can always punt.

--
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

Reply via email to