[
https://issues.apache.org/jira/browse/HBASE-24590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17158024#comment-17158024
]
Viraj Jasani commented on HBASE-24590:
--------------------------------------
{quote}For example, if someone changes region replica count, we also need to
add/remove additional replicas before enabling the table.
{quote}
If we are planning to support everything that ModifyTableProcedure allows to
update, then yes this is the only way but the question is do we want to allow
updating all attributes? IMHO clone_snapshot is a special case where limited
attributes should be allowed for modification.
However, I agree that using ModifyTableProcedure as a child procedure should be
better option and we should also think about what limited attributes, we are
planning to support or which attributes we don't want to support with
clone_snapshot, provide validation for the same, document it accordingly, and
we should be good to go. WDYT?
> 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)
