hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-13993) WALProcedureStore fencing is not effective if new WAL rolls
Date Tue, 30 Jun 2015 00:42:04 GMT

     [ https://issues.apache.org/jira/browse/HBASE-13993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Enis Soztutar updated HBASE-13993:
    Attachment: hbase-13993_v1.patch

Here is a posible patch. We re-check the max logId from the old logs everytime we do a WAL
roll to make sure that there has not been any WALs created with a higher logId. This should
guarantee that deleted WALs will not cause fencing to be ineffective with WAL rolls. 

This patch depends on HBASE-13832, but the tests hang for now with the v1 patch there. 

> WALProcedureStore fencing is not effective if new WAL rolls 
> ------------------------------------------------------------
>                 Key: HBASE-13993
>                 URL: https://issues.apache.org/jira/browse/HBASE-13993
>             Project: HBase
>          Issue Type: Sub-task
>          Components: master
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 2.0.0, 1.2.0, 1.1.2, 1.3.0
>         Attachments: hbase-13993_v1.patch
> WAL fencing for the WALProcedureStore is a bit different than the fencing done for region
server WALs. 
> In case of this sequence of events, the WAL is not fenced (especially with HBASE-13832
>  - master1 creates WAL with logId = 1: {{/MasterProcWALs/state-00000000000000000001.log}}

>  - master2 takes over, fences logId = 1 with recoverLease(), creates logId=2: {{/MasterProcWALs/state-00000000000000000002.log}}.
>  - master2 writes some procedures and rolls the logId2, and creates logId = 3, and deletes
logId = 2. 
>  - master1 now tries to write a procedure, gets lease mismatch, rolls the log from 1
to 2, and succeeds the write since it can write logId = 2 (master2 uses logId=3 now). 

This message was sent by Atlassian JIRA

View raw message