Jerry He commented on HBASE-16672:
The stack trace looks confusing.
1. Why incremental restore was bulk loading the file paths that are in an
existing table? The incremental restore should be restoring files from the
backup image. The files in the backup image may be coming from the existing
table originally. But the files should be physically in the backup image. This
is different from the snapshot restore, where it is a in-place restore.
2. What the snapshot failed with the missing file?
An bulk load option to keep the original files (not move/rename them to target)
seems a fine option. We can simplify the JIRA description to describe just
that, without the confusing stack trace.
> Add option for bulk load to copy hfile(s) instead of renaming
> Key: HBASE-16672
> URL: https://issues.apache.org/jira/browse/HBASE-16672
> Project: HBase
> Issue Type: Improvement
> Reporter: Ted Yu
> Assignee: Ted Yu
> Attachments: 16672.v1.txt, 16672.v2.txt, 16672.v3.txt, 16672.v4.txt
> While working on HBASE-14417, I found that taking full backup of table which
> received bulk loaded hfiles and later gone through incremental restore failed
> with the following exception:
> 2016-09-21 11:33:06,340 WARN [member: '10.22.9.171,53915,1474482617015'
> snapshot.RegionServerSnapshotManager$SnapshotSubprocedurePool(347): Got
> Exception in SnapshotSubprocedurePool
> java.util.concurrent.ExecutionException: java.io.FileNotFoundException: File
> does not exist:
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:192)
> The cause was that the bulk loaded hfiles in source table were renamed during
> bulk load step of incremental restore.
> To support incrementally restoring to multiple destinations, this issue adds
> option which would always copy hfile(s) during bulk load.
This message was sent by Atlassian JIRA