[
https://issues.apache.org/jira/browse/HBASE-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13676308#comment-13676308
]
stack commented on HBASE-7006:
------------------------------
On 'Concern One', we would get back B. The B would be in memstore when region
was flipped readable. memstore gets precedence over hfiles. We should get
back C though. Even if we held up flushes until the region were flipped to
readable, we'd have a problem (because B coming in later would overwrite C).
But Jeffrey, don't you have replayed edits go into a different memstore? Or if
you don't, maybe they should... and this other memstore should sort after the
first memstore? You could flush the memstore of replayed edits but not the
memstore of new edits, not until the region had flipped readable?
(Good find E and H).
On concern two, what Jeffrey says above, we suppress versions of same timestamp
so only the latest version of a timestamp returned so we'd get 12, 11, 10.
> [MTTR] Improve Region Server Recovery Time - Distributed Log Replay
> -------------------------------------------------------------------
>
> Key: HBASE-7006
> URL: https://issues.apache.org/jira/browse/HBASE-7006
> Project: HBase
> Issue Type: New Feature
> Components: MTTR
> Reporter: stack
> Assignee: Jeffrey Zhong
> Priority: Critical
> Fix For: 0.98.0, 0.95.1
>
> Attachments: 7006-addendum-3.txt, hbase-7006-addendum.patch,
> hbase-7006-combined.patch, hbase-7006-combined-v1.patch,
> hbase-7006-combined-v4.patch, hbase-7006-combined-v5.patch,
> hbase-7006-combined-v6.patch, hbase-7006-combined-v7.patch,
> hbase-7006-combined-v8.patch, hbase-7006-combined-v9.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
