accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Created] (ACCUMULO-3310) Garbage collection might remove files with references in the replication table
Date Thu, 06 Nov 2014 21:08:33 GMT
Christopher Tubbs created ACCUMULO-3310:
-------------------------------------------

             Summary: Garbage collection might remove files with references in the replication
table
                 Key: ACCUMULO-3310
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3310
             Project: Accumulo
          Issue Type: Bug
          Components: replication
            Reporter: Christopher Tubbs
            Assignee: Josh Elser
             Fix For: 1.7.0


There's a possible race condition deleting files from HDFS still needed for replication. The
Accumulo garbage collector will not check for references to files in use if it thinks that
the replication table does not exist (or is offline, as the case will be after ACCUMULO-3147
is completed). The problem with this is that the table may actually exist, and may be the
only place where the in-use file is still referenced, but the garbage collector may not yet
know the table exists.

This probably has a very low probability of happening, and only really affects the case when
replication is first started. However, if it did happen, it would mean an error replicating
data.

Some solutions discussed with [~elserj]:
# Always scan the table. _This requires the table to always exist and be online and available
for scanning._
# Keep the status messages around until after they are removed from the replication table.
This requires moving the deletes from {{StatusMaker}} to {{RemoveCompleteReplicationRecords}}.
_There may be some implications for delaying removal of these entries, but probably not too
many, and none we can't work through._
# Move the contents of the replication table to the metadata table and don't have a separate
replication table. _This would require a big refactoring, and might have performance implications
to the metadata table._



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message