accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (ACCUMULO-3310) Garbage collection might remove files with references in the replication table
Date Thu, 26 Mar 2015 21:49:53 GMT

     [ https://issues.apache.org/jira/browse/ACCUMULO-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Josh Elser updated ACCUMULO-3310:
---------------------------------
    Assignee:     (was: Josh Elser)

> 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
>             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