[ 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 patch): > - 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 (v6.3.4#6332)