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 > >
