accumulo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dickson, Matt MR" <matt.dick...@defence.gov.au>
Subject RE: Droptable hanging [SEC=UNOFFICIAL]
Date Mon, 02 Jun 2014 05:26:28 GMT
UNOFFICIAL

Thanks for the responses to my question.

After removing the locks in zookeeper for the table the deletion completed :)   Interestingly
the Accumulo console showed no stats agains the table other than the state being in 'DELETING'.
 Next time I'll check the zookeeper table_locks and table directories to see what Zookeeper
has also.

________________________________
From: Sean Busbey [mailto:busbey@cloudera.com]
Sent: Monday, 2 June 2014 12:17
To: Accumulo User List
Subject: Re: Droptable hanging [SEC=UNOFFICIAL]

Be careful taking the table offline if you have other tables still active. Presuming this
table was active (and that's why the unloading tablets it taking awhile) you might run into
ACCUMULO-2694. That would keep other tables from balancing while you wait for the delete.

https://issues.apache.org/jira/browse/ACCUMULO-2694

Matt, how many tablets are in this table?

Are you concerned about the time it takes to delete or just the warning in the shell?

FWIW, once you've issued a table delete, you can force exit the shell instance and the delete
will continue asynchronously. If you need to recreate the table, doing a rename+delete will
let the delete proceed while you create the new table.


On Sun, Jun 1, 2014 at 6:40 PM, Josh Elser <josh.elser@gmail.com<mailto:josh.elser@gmail.com>>
wrote:

I believe that the master will wait for all of the tablets for that table to become unassigned
before it will delete it. This tends to be the underlying cause of table ops that want to
hang. For example, a bunch of minor compactions that need to finish would also prevent unloading
those tablets.

I'm not sure if it would help (or if it would even work :P), but you could try to offline
the table first.

Hypothetically, you could delete the files and references in the metadata table, but that
would be rather manual. Its possible it would work though. You may also have to do some cleanup
in ZK too.

But, the underlying question is still: why is the table not getting deleted?

Can you share stacktraces from tserver(s) hosting tablets for the table you're trying to delete
(along with the usual version info)? Are there queued/running compactions for that table?

On Jun 1, 2014 5:56 PM, "Dickson, Matt MR" <matt.dickson@defence.gov.au<mailto:matt.dickson@defence.gov.au>>
wrote:

UNOFFICIAL

When dropping a table the shell hangs with "thread 'shell' stuck on IO to ipaddress (0) for
at least ...ms

Is there a way to drop the table other than via the shell?  eg can the hdfs rfiles all be
deleted under /accumulo/tables/id/...  and then remove all references to the table in the
!METADATA table.  Or are there other references to the table that need removing?



--
Sean

Mime
View raw message