[GitHub] [accumulo] keith-turner commented on issue #1998: Decide behavior of external compactions when a table is taken offline.

[GitBox <gi...@apache.org>]

keith-turner commented on issue #1998:
URL: https://github.com/apache/accumulo/issues/1998#issuecomment-818026878


   >Are there sanity checks in place that verify that the input files for the external compaction are still in the current set of files for the tablet when the external compaction is committed?
   
   Yeah that is done by the following sanity check which existed before external compactions.
   
   https://github.com/apache/accumulo/blob/183387ab6de5c82ed23f9b236a76ea7fce669be4/server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/DatafileManager.java#L424
   
   > For example, a new table created offline probably won't be affected but I am not sure about exportTable, table clone, bulk imports, or the offline scan map reduce option. Also didn't we add offline splits in 2.0 as well?
   
   As currently implemented external compactions running against a table that is offline do not commit (update tablet metadata) until the table comes back online.  So this should not impact any of those operations.  Also if when the table comes back online the tablet for the ext compaction no longer exists for some reason (like split/merge), then the commit operation will be a no-op.
   
   I think all of these cases you mentioned are good reasons to never commit an external compaction in an offline table.  Which was something I was uncertain about.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
users@infra.apache.org