[
https://issues.apache.org/jira/browse/HBASE-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13647252#comment-13647252
]
Anoop Sam John commented on HBASE-7006:
---------------------------------------
[~jeffreyz] I also had the same question as from Stack regarding the WAL. This
might be very important. Also now we will allow the writes on the recovering
region when this replay is happening. These other writes + replays might be
doing flushes in btw.. Any way replays alone also might be doing flushes in
between(because of memstore sizes).. When this replays are in progress for
some regions opened in a RS, now the replay requests from other RS taking some
handlers. Whether this will affect the normal functioning of the RS? May be
we can test this also IMO. The cluster is normal functioning with read,writes
and then this RS down happens. So whether/how it will impact the normal read
write throughput.
> [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
