You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Viraj Jasani (Jira)" <ji...@apache.org> on 2020/07/15 09:40:00 UTC

[jira] [Commented] (HBASE-24590) Clone snapshot with optional table level property overrides

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