Can’t drop it. HBase doesn’t think the table exists. On Sep 25, 2014, at 12:50 PM, Ted Yu <[email protected]> wrote:
> You can drop the table (run hbck afterwards if necessary). > Then restore again. > > If it hangs again, please capture stack trace. > > Cheers > > On Thu, Sep 25, 2014 at 9:32 AM, Brian Jeltema < > [email protected]> wrote: > >> The table did not exist on the target cluster when I tried the first >> restore_clone. >> Is there some way I can delete all traces of the table and start over? >> >> On Sep 25, 2014, at 12:25 PM, Ted Yu <[email protected]> wrote: >> >>> It is from the following in CloneSnapshotHandler.java : >>> >>> Preconditions.checkArgument(!metaChanges.hasRegionsToRestore(), >>> >>> "A clone should not have regions to restore"); >>> >>> Was there region split prior to snapshot restore action ? >>> >>> Cheers >>> >>> On Thu, Sep 25, 2014 at 9:19 AM, Brian Jeltema < >>> [email protected]> wrote: >>> >>>> I exported a snapshot to another cluster, same version of all software. >> A >>>> restore_snapshot on the target >>>> system hung and eventually timed out, I think due to file ownership >>>> issues. I restored hbase ownership >>>> to everything in /apps/hbase and tried the restore_snapshot again. It’s >>>> still hanging, but in the master logs I’m seeing: >>>> >>>> clone snapshot={ ss=foo-9-25-14 table=Foo type=FLUSH } failed because >> A >>>> clone should not have regions to restore >>>> >>>> However, I was able to do a clone_snapshot to a table with a different >>>> name. Does anyone know >>>> what this means and how to get past it? (HBase 0.98) >>>> >>>> Thanks >>>> Brian >> >>
