[
https://issues.apache.org/jira/browse/HBASE-15046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15073563#comment-15073563
]
Lars Hofhansl commented on HBASE-15046:
---------------------------------------
bq. Currently, sync WAL is not really 'sync' (it use hflush not hsync). So with
'rollback memstore', it may cause inconsistency between WAL and memstore. I am
not sure the tradeoff between performance and correctness?
Not so. hflush might not persist to disk (just forces changes to the typically
3 involved data nodes), but it is the point at the we report back to the client
that the write was successful, no amount of reordering mvcc and hflush can
guard against (say) a power outage taking the wrong three machines down.
[~eclark] and [~stack], so this is possible after HBASE-12751 (which is in
master, only)? That would be cool simplification indeed.
> Perf test doing all mutation steps under row lock
> -------------------------------------------------
>
> Key: HBASE-15046
> URL: https://issues.apache.org/jira/browse/HBASE-15046
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
>
> This issue is about perf testing a redo of the write pipeline so that rather
> than:
> * take rowlock
> * start mvcc
> * append to WAL
> * add to memstore
> * sync WAL
> * let go of rowlock
> * finish up mvcc
> instead.... try...
> * take rowlock
> * start mvcc
> * append to WAL
> * sync WAL
> * add to memstore
> * finish up mvcc
> * let go of rowlock
> The latter is more straight-forward undoing need of rolling back memstore if
> all does not succeed.
> It might be slower though. This issue is a look-see/try it.
> The redo will also help address the parent issue in a more general way so we
> can do without the special-casing done for branch-1.0 and branch-1.1 done in
> a sibling subtask.
> Other benefits are that the current write pipeline is copy/pasted in a few
> places -- in append, increment and checkand* -- and a refactor will allow us
> to fix this duplication.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
