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] [Comment Edited] (ACCUMULO-2974) Unable to assign single tablet table migrated to 1.6.0
Date Fri, 04 Jul 2014 04:20:33 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-2974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14052147#comment-14052147
] 

Josh Elser edited comment on ACCUMULO-2974 at 7/4/14 4:18 AM:
--------------------------------------------------------------

No worries, [~busbey], I just re-pro'ed it pretty easily. It actually appears to be an issue
with a delete merge (e.g. deleterows in the shell) on a table that has relative paths from
1.5.

Edit: oops, I don't think having splits or not is relevant.


was (Author: elserj):
No worries, [~busbey], I just re-pro'ed it pretty easily. It actually appears to be an issue
with a delete merge (e.g. deleterows in the shell) on a table with no splits that has relative
paths from 1.5.

> Unable to assign single tablet table migrated to 1.6.0
> ------------------------------------------------------
>
>                 Key: ACCUMULO-2974
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-2974
>             Project: Accumulo
>          Issue Type: Bug
>          Components: master
>    Affects Versions: 1.6.0
>            Reporter: John Vines
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 1.6.1, 1.7.0
>
>         Attachments: 0001-ACCUMULO-2974-Include-the-table-id-when-constructing.patch,
badMetaScan.png, goodMetaScan.png, stackTrace.png
>
>
> Sorry for the screen caps, no copy/paste from machines.
> Background- several tables migrated from 1.5.1 to 1.6.0. Only one of which was a single
tablet. Upon starting, we noticed that that single table was not loading and the master was
reporting an unassigned tablet. Had a stack trace in the monitor (attached).
> Also attached is a a metadata scan of the table in question (ID: 12). I was able to get
a functional copy of the table by offlining 12 and cloning it. It functioned without issues.
Attached is a copy of it's metadata scan as well (ID: 9o)
> The stack trace leads me to it being a specific issue with the contents of srv:dir, and
the only difference is the relative vs. absolute file names. This cluster was not changed
to multiple namenodes and ../tables/default_tablet does not exist. There are other tables
which still use the relative naming scheme, and the system does not seem to be having issues
with them.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message