[
https://issues.apache.org/jira/browse/HBASE-24590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140513#comment-17140513
]
Viraj Jasani edited comment on HBASE-24590 at 6/19/20, 12:49 PM:
-----------------------------------------------------------------
+1 to this idea, it would be real nice to have override attributes with
clone_snaoshot.
However, from impl point of view, we already have tableDescriptor for step
CLONE_SNAPSHOT_WRITE_FS_LAYOUT to create regions in file system using
tableDescriptor. So why not let SnapshotManager take care of updating
tableDescriptor with overriding all desired attribute values that we are
planning to introduce as part of this Jira, and pass it on to
CloneSnapshotProcedure? That way not only we require any additional step in
CloneSnapshotProcedure, but also the responsibility of overriding attribute
remains with SnapshotManager.
Thought?
was (Author: vjasani):
+1 to this idea, it would real nice to have override attributes with
clone_snaoshot.
However, from impl point of view, we already have tableDescriptor for step
CLONE_SNAPSHOT_WRITE_FS_LAYOUT to create regions in file system using
tableDescriptor. So why not let SnapshotManager take care of updating
tableDescriptor with overriding all desired attribute values that we are
planning to introduce as part of this Jira, and pass it on to
CloneSnapshotProcedure? That way not only we require any additional step in
CloneSnapshotProcedure, but also the responsibility of overriding attribute
remains with SnapshotManager.
Thought?
> Clone snapshot with optional table level property overrides
> -----------------------------------------------------------
>
> Key: HBASE-24590
> URL: https://issues.apache.org/jira/browse/HBASE-24590
> Project: HBase
> Issue Type: Improvement
> Components: API, master, shell
> Affects Versions: 3.0.0-alpha-1, 2.3.0, 1.6.0
> Reporter: Bharath Vissapragada
> Priority: Minor
>
> We have this use case where we try to clone from snapshots of a table with
> replication enabled. Cloning process just reads the TableDescriptor from the
> manifest and uses it for the new target table.
> In our case, the moment we clone it, replication kicks in and attempts to
> replicate table to peers but since the target table doesn't exist, it keeps
> throwing TNFE in a loop. I propose to add additional *optional* parameters to
> clone_snapshot that takes the target table property overrides (table leve/cf
> level).
> For example:
> {noformat}
> clone_snapshot 'snapshotName', 'tableName' # default
> clone_snapshot 'snapshotName', 'tableName', {NAME => 'f1', REPLICATION_SCOPE
> => 0 }
> clone_snapshot 'snapshotName, 'tableName', {MERGE_ENABLED => false}
> .....
> {noformat}
>
> Implementation wise, this just adds a {{ModifyTableProcedure}} as a child
> procedure (if args are provided) for {{CloneSnapshotProcedure}} after
> {{CLONE_SNAPSHOT_ADD_TO_META}}, so we reuse most of the "modifyTable" code.
> Also, since clone puts the table in a disabled state, using
> "ModifyTableProcedure" shouldn't cause any issues.
> Thoughts? Is there any easier way to do it?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
