Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 22 Mar 2016 04:05:25 +0000 (UTC)
From: "Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12947773.1457380175000.13643.1458619525664@Atlassian.JIRA>
In-Reply-To: <JIRA.12947773.1457380175000@Atlassian.JIRA>
References: <JIRA.12947773.1457380175000@Atlassian.JIRA>
 <JIRA.12947773.1457380175984@arcas>
Subject: [jira] [Comment Edited] (HBASE-15411) Rewrite backup with Procedure
 V2
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-15411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15205738#comment-15205738 ] 

Ted Yu edited comment on HBASE-15411 at 3/22/16 4:04 AM:
---------------------------------------------------------

bq. Lets gather these arguments in a client-public class like BackupRequest

I went through existing methods in Admin.java but didn't see such pattern. Since BackupRequest is not protobuf'ed, when new field is introduced, compilation would break anyway.

bq. Where is the removed code, for example BackupHandler etc?

Yes, the code in FullTableBackupProcedure.java came from BackupHandler.
I would suggest keeping FullTableBackupProcedure and BackupHandler close for phase I so that Vlad's work in phase 2 can be easily picked up.

bq. This workers is being carried all the way from the client.

The workers parameter would be used once we come to rebasing Vlad's phase 2 work.

bq. we want exclusive lock on the table, not shared, no?

After offline discussion with Stephen, we chose shared locks.


was (Author: yuzhihong@gmail.com):
bq. Lets gather these arguments in a client-public class like BackupRequest

I went through existing methods in Admin.java but didn't see such pattern. Since BackupRequest is not protobuf'ed, when new field is introduced, compilation would break anyway.

bq. Where is the removed code, for example BackupHandler etc?

Yes, the code in FullTableBackupProcedure.java came from BackupHandler.
I would suggest keep FullTableBackupProcedure and BackupHandler close for phase I so that Vlad's work in phase 2 can be easily picked up.

bq. This workers is being carried all the way from the client.

The workers parameter would be used once we come to rebasing Vlad's phase 2 work.

bq. we want exclusive lock on the table, not shared, no?

After offline discussion with Stephen, we chose shared locks.

> Rewrite backup with Procedure V2
> --------------------------------
>
>                 Key: HBASE-15411
>                 URL: https://issues.apache.org/jira/browse/HBASE-15411
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Ted Yu
>            Assignee: Ted Yu
>         Attachments: 15411-v1.txt, 15411-v11.txt, 15411-v12.txt, 15411-v13.txt, 15411-v14.txt, 15411-v15.txt, 15411-v16.txt, 15411-v18.txt, 15411-v3.txt, 15411-v5.txt, 15411-v6.txt, 15411-v7.txt, 15411-v9.txt, FullTableBackupProcedure.java
>
>
> Currently full / incremental backup is driven by BackupHandler (see call() method for flow).
> This issue is to rewrite the flow using Procedure V2.
> States (enum) for full / incremental backup would be introduced in Backup.proto which correspond to the steps performed in BackupHandler#call().
> executeFromState() would pace the backup based on the current state.
> serializeStateData() / deserializeStateData() would be used to persist state into procedure WAL.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)