[
https://issues.apache.org/jira/browse/HBASE-12988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14609183#comment-14609183
]
Andrew Purtell commented on HBASE-12988:
----------------------------------------
bq. The reason is that we'd have to regroup the edits with the writetime and
sequencenumber under which they originated. Since each Entry (WALKey, WALEdit
pair) has a unique sequencenumber we cannot pull the edits apart...
Yes, but:
bq. The WALKey (formerly HLogKey) also has logSeqNum and writeTime. Right now
the sink only uses the writeTime to update ageOfLastAppliedOp. If ever we want
to use them - for ordering or other guarantees - we cannot disentangle them
from the WALEdits; i.e. we cannot regroup Cell between WALEdits.
So we are not using the WALKey sequence number. Any pressing reason why we
should? If not we can deprecate and remove it. Likewise, we can document that
writeTime is informational and does not provide a guarantee of ordering.
> [Replication]Parallel apply edits on row-level
> ----------------------------------------------
>
> Key: HBASE-12988
> URL: https://issues.apache.org/jira/browse/HBASE-12988
> Project: HBase
> Issue Type: Improvement
> Components: Replication
> Reporter: hongyu bi
> Assignee: Lars Hofhansl
> Attachments: 12988-v2.txt, 12988-v3.txt, 12988.txt,
> HBASE-12988-0.98.patch, ParallelReplication-v2.txt
>
>
> we can apply edits to slave cluster in parallel on table-level to speed up
> replication .
> update : per conversation blow , it's better to apply edits on row-level in
> parallel
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
