Some progress on this issue -
If I stop the master then I can delete the fate transaction from zookeeper.
First I used "accumulo org.apache.accumulo.server.fate.Admin print | grep
CompactRange" to find the transactions and then "accumulo o.a.a.s.f.Admin
delete <id>" to delete it. Started the master back up, manually peeked in
zookeeper, and the transaction was gone. That said, looking at the monitor
page there are still all of my compactions queued up, so I don't think that
actually did anything. Is there another place that I need to look?
I saw that zk has /accumulo/<id>/tables/<tid>/compact-id entry, but I don't
know how that relates.
On Wed, May 15, 2013 at 2:56 AM, John Vines <[EMAIL PROTECTED]> wrote:
> I do not believe there is a way to tell a tserver to cancel all
> compactions. It would be a nice feature though. Mind putting on a ticket?
> Sorry for the dupe mike, missed hitting reply all
> Sent from my phone, please pardon the typos and brevity.
> On May 14, 2013 11:54 PM, "Mike Drob" <[EMAIL PROTECTED]> wrote:
>> Can I leave the ones that are already running and just dispose of the
>> queued compactions? If not, that seems like a pretty serious limitation.
>> On Wed, May 15, 2013 at 2:51 AM, John Vines <[EMAIL PROTECTED]> wrote:
>>> I'm not sure if it's possible. Scheduling a compaction is an entry in
>>> the metadata table. But once it gets triggered, there are then compactions
>>> scheduled locally for the tserver. You might be able to delete the flag and
>>> bounce all the tservers to stop it, but I can't say for certain.
>>> Sent from my phone, please pardon the typos and brevity.
>>> On May 14, 2013 11:48 PM, "Mike Drob" <[EMAIL PROTECTED]> wrote:
>>>> Somebody (totally not me) accidentally kicked off a full table
>>>> compaction using Accumulo 1.4.3.
>>>> There's a large number of them waiting and the queue is decreasing very
>>>> slowly - what are my options for improving the situation. Ideally, I would
>>>> be able to just cancel everything and then come back with a more precise