recovered.edits files not deleted if it only contain edits that have already
been flushed; hurts performance every future region open
-------------------------------------------------------------------------------------------------------------------------------------
Key: HBASE-3015
URL: https://issues.apache.org/jira/browse/HBASE-3015
Project: HBase
Issue Type: Bug
Reporter: Kannan Muthukkaruppan
On RS crash, master processes the RS's logs, splits them into per region log
files, and puts them in recovered.edits sub-directory of the region.
It may be the case the some of these files contain only old edits (that have
already been flushed), and don't need to be reapplied again. However, in this
case the file is not deleted, and stays in recovered.edits for ever. This will
slow down every future "open" of this region, as the region will unnecessarily
spend time processing this file.
In HRegion.java:replaceRecoveredEditsIfAny(), the code below checks if the
file we just processed contain any edits that were applied, and in that case
flushes the memstore into which things were being recovered.
{code}
if (seqid > minSeqId) {
// Then we added some edits to memory. Flush and cleanup split edit files.
internalFlushcache(null, seqid);
for (Path file: files) {
if (!this.fs.delete(file, false)) {
LOG.error("Failed delete of " + file);
} else {
LOG.debug("Deleted recovered.edits file=" + file);
}
}
}
{code}
But it is not clear why the 'for' loop to clean up the recovered.edits file is
inside the if check.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
