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

Jeffrey Zhong commented on HBASE-7006:
--------------------------------------

Hey Ram,
Thanks for the good questions. Below are the answers:
1) 







{code}
catch (KeeperException e) {
+        LOG.warn("Cannot get lastFlushedSequenceId from ZooKeeper for server=" 
+ regionServerName
+            + "; region=" + encodedRegionName, e);
+      }
{code}
In this scenario, we can't get last flushed sequence Id so we'll replay all 
edits in the wal. There will be some duplicated replay while it won't affect 
correctness.








{code}
+    } catch (KeeperException e) {
+      LOG.warn("Cannot remove recovering regions from ZooKeeper", e);
+    }
{code}
We have other place to do stale data GC. Therefore, after a little bit, the 
recovering ZK node should be removed:
In SplitLogManager, we have following code:















      // Garbage collect left-over /hbase/recovering-regions/... znode
      if (tot == 0 && inflightWorkItems.size() == 0 && tasks.size() == 0) {
        removeRecoveringRegionsFromZK(null);
      }
-Jeffrey
                                          

                
> [MTTR] Study distributed log splitting to see how we can make it faster
> -----------------------------------------------------------------------
>
>                 Key: HBASE-7006
>                 URL: https://issues.apache.org/jira/browse/HBASE-7006
>             Project: HBase
>          Issue Type: Bug
>          Components: MTTR
>            Reporter: stack
>            Assignee: Jeffrey Zhong
>            Priority: Critical
>             Fix For: 0.95.1
>
>         Attachments: hbase-7006-combined.patch, hbase-7006-combined-v1.patch, 
> LogSplitting Comparison.pdf, 
> ProposaltoimprovelogsplittingprocessregardingtoHBASE-7006-v2.pdf
>
>
> Just saw interesting issue where a cluster went down  hard and 30 nodes had 
> 1700 WALs to replay.  Replay took almost an hour.  It looks like it could run 
> faster that much of the time is spent zk'ing and nn'ing.
> Putting in 0.96 so it gets a look at least.  Can always punt.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to