You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Christopher Tubbs (Jira)" <ji...@apache.org> on 2020/03/06 02:11:00 UTC

[jira] [Resolved] (ACCUMULO-3310) Garbage collection might remove files with references in the replication table

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

Christopher Tubbs resolved ACCUMULO-3310.
-----------------------------------------
    Resolution: Incomplete

This bug was reported several years ago, and does not appear to have been actively pursued by anybody. It was closed as "Incomplete" to clean up old JIRA issues after migrating issues to GitHub.

If anybody is interested in working on this, please create a new issue at our current issue tracker at https://github.com/apache/accumulo/issues

> 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
>            Priority: Major
>
> 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
(v8.3.4#803005)