[
https://issues.apache.org/jira/browse/HBASE-21354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659130#comment-16659130
]
stack commented on HBASE-21354:
-------------------------------
bq. What's your concern, sir stack? I think DEBUG is enough.
These transitions are critical so they should be INFO-level. Most folks run
INFO-level so if an accounting issue around Master Proc WALs, they'll miss
critical info. We do INFO level for regionserver WALs.
Thanks for note on your thoughts on what sort of mis-deletes this patch avoids.
> Procedure may be deleted improperly during master restarts resulting in
> 'Corrupt'
> ---------------------------------------------------------------------------------
>
> Key: HBASE-21354
> URL: https://issues.apache.org/jira/browse/HBASE-21354
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.1.0, 2.0.2
> Reporter: Allan Yang
> Assignee: Allan Yang
> Priority: Major
> Attachments: HBASE-21354.branch-2.0.001.patch,
> HBASE-21354.branch-2.0.002.patch, HBASE-21354.branch-2.0.003.patch,
> HBASE-21354.branch-2.0.004.patch
>
>
> Good news! [~stack], [~Apache9], I may find the root cause of mysterious
> ‘Corrupted procedure’ or some procedures disappeared after master
> restarts(happens during ITBLL).
> This is because during master restarts, we load procedures from the log, and
> builds the 'holdingCleanupTracker' according each log's tracker. We may mark
> a procedure in the oldest log as deleted if one log doesn't contain the
> procedure. This is Inappropriate since one log will not contain info of the
> log if this procedure was not updated during the time. We can only delete the
> procedure only if it is not in the global tracker, which have the whole
> picture.
> {code}
> trackerNode = tracker.lookupClosestNode(trackerNode, procId);
> if (trackerNode == null || !trackerNode.contains(procId) ||
> trackerNode.isModified(procId)) {
> // the procedure was removed or modified
> node.delete(procId);
> }
> {code}
> A test case(testProcedureShouldNotCleanOnLoad) shows cleanly how the
> corruption happened in the patch.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
