[
https://issues.apache.org/jira/browse/HBASE-26286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17436008#comment-17436008
]
Wellington Chevreuil commented on HBASE-26286:
----------------------------------------------
{noformat}
My suggestion would be to drop restore from the scope. Because if changing
otherwise untouched regions should be avoided than our Descriptor granularity
is insufficient for this task. If changing regions untouched by restore is
acceptable, I would argue doing a traditional restore and using the already
existing migration logic is a cleaner solution than mixing it with snapshot
restore.
{noformat}
I'm on alright with supporting this for clone only. But now that you raised
problem above, I'm worried with the corner case where we changed the SFT impl
definition in the table after a snapshot was taken, then when we try to restore
the snapshot, what would happen with any "untouched" region? I guess the
easiest solution would be to change restore logic, to add extra checks for
change in the SFT config in the very beginning, failing the restore if SFT
config diverges, asking operator to migrate table SFT config to same from the
snapshot, before trying restore.
> Add support for specifying store file tracker when restoring or cloning
> snapshot
> --------------------------------------------------------------------------------
>
> Key: HBASE-26286
> URL: https://issues.apache.org/jira/browse/HBASE-26286
> Project: HBase
> Issue Type: Sub-task
> Components: HFile, snapshots
> Reporter: Duo Zhang
> Assignee: Szabolcs Bukros
> Priority: Major
>
> As discussed in HBASE-26280.
> https://issues.apache.org/jira/browse/HBASE-26280?focusedCommentId=17414894&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17414894
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
