[
https://issues.apache.org/jira/browse/HBASE-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593455#action_12593455
]
stack commented on HBASE-610:
-----------------------------
Regards my scenario above, I don't think its possible. Upon review,
regionservers update using no explicit timestamp. Means that their edits get
applied using the current time of the regionserver hosting the region taking on
the edits, not that of the regionserver who is in the past. HBASE-609's
problem was that master was asking to open scanner on a .META. region using an
explicit time, the current time on the master... not current time on hosting
regionserver.
> Autoincrementing cell version
> -----------------------------
>
> Key: HBASE-610
> URL: https://issues.apache.org/jira/browse/HBASE-610
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: stack
> Fix For: 0.2.0
>
>
> HBASE-609 has an example of clock skew making it so master scanner missed
> edits placed there by a regionserver whose clock was in advance of the
> masters. There may be other cases lurking where this kind of issue -- two
> servers are updating a particular row with off-clocks -- may bite us. Could
> a regionserver that has a clock a long ways behind the running master's clock
> enter a split record that went in behind the current inforegion cell's
> version? If so, the master wouldn't see the split.
> One fix would be a new feature where cells had a version that autoincremented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
