[ 
https://issues.apache.org/jira/browse/HBASE-20066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375566#comment-16375566
 ] 

Duo Zhang commented on HBASE-20066:
-----------------------------------

After some digging, I found it is really hard to always keep the sequence id 
increasing for failover. We can fail at any place, and then we need to inject 
the write sequence id logic at many places, but it is still not perfect. It is 
OK to write a sequence id after write the close region marker, if it fails, the 
RS will abort and the marker will be replayed so we can get the correct max 
sequence id. But for a region open, if we fails after write the open region 
marker, then we are dead... Because the region has not been opened on this RS 
yet, so even if we abort the RS, we will not replay the log so we can not know 
that there is a open region marker...

So, I think we could try to do it better for split and merge, where we can 
write a max sequence id file for the newly generated regions. But for failover, 
let's keep it as is, since we can not solve all the problem but will make the 
code much complicated.

[~stack] What do you think sir?

Thanks.

> Region sequence id may go backward after split or merge
> -------------------------------------------------------
>
>                 Key: HBASE-20066
>                 URL: https://issues.apache.org/jira/browse/HBASE-20066
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Duo Zhang
>            Priority: Critical
>
> The problem is that, now we have markers which will be written to WAL but not 
> in store file. For a normal region close, we will write a sequence id file 
> under the region directory, and when opening we will use this as the open 
> sequence id. But for split and merge, we do not copy the sequence id file to 
> the newly generated regions so the sequence id may go backwards since when 
> closing the region we will write flush marker and close marker into WAL...



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to