[
https://issues.apache.org/jira/browse/HBASE-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13675646#comment-13675646
]
Elliott Clark commented on HBASE-7006:
--------------------------------------
bq.In step 3, how would C carry timestamp 0 which is the same as A and B ?
You can specify the timestamp on put's. 0 isn't special here. It could be any
timestamp that's the same.
So I bring up the seqId as a concern because of:
* http://archive.apache.org/dist/hbase/docs/versions.html#d397e2960
** "To overwrite an existing value, do a put at exactly the same row, column,
and version as that of the cell you would overshadow."
*
https://issues.apache.org/jira/browse/HBASE-7763?focusedCommentId=13572592&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13572592
*
http://hbase.apache.org/xref/org/apache/hadoop/hbase/regionserver/KeyValueHeap.html#176
Things in the memstore may be upserted (Probably a bug that should be doc'd or
addressed). But sequence Id sorting is the reason that compaction must always
choose contiguous files. If that changes then the compaction algorithm can be
very different from what it currently is.
> [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
