Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 27 Feb 2017 13:41:45 +0000 (UTC)
From: "Ashish Singhi (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13034537.1484297434000.6057.1488202905426@Atlassian.JIRA>
In-Reply-To: <JIRA.13034537.1484297434000@Atlassian.JIRA>
References: <JIRA.13034537.1484297434000@Atlassian.JIRA> <JIRA.13034537.1484297434859@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-17460) enable_table_replication can not
 perform cyclic replication of a table
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 27 Feb 2017 13:41:56 -0000


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

Ashish Singhi commented on HBASE-17460:
---------------------------------------

ReplicationAdmin#enableTableRep is a public API from a interface audience public class, we cannot change the method signature just like that.

Earlier ReplicationAdmin#enableTableRep behavior was, user was allowed to enable replication on a CF later also if user didn't do it the first time, but with this change user will not be able to do this using this API.
Is it really required to check for localHtd.isReplicationEnabled() and throw exception even if its enabled on some CF and not all, what will happen if we do not do ?

Sorry for being later here,
The jira was raised for handling cyclic replication in ReplicationAdmin#enableTableRep API, for that I think the simple fix would have been just to avoid the replication scope check for source and peer HTD. But looks like we have introduced a behavior change in a public API :(

> enable_table_replication can not perform cyclic replication of a table
> ----------------------------------------------------------------------
>
>                 Key: HBASE-17460
>                 URL: https://issues.apache.org/jira/browse/HBASE-17460
>             Project: HBase
>          Issue Type: Bug
>          Components: Replication
>            Reporter: NITIN VERMA
>            Assignee: NITIN VERMA
>              Labels: incompatibleChange, replication
>             Fix For: 2.0.0
>
>         Attachments: 17460-addendum.txt, 17460-addendum.v2.txt, 17460.branch-1.v3.txt, 17460.v5.txt, HBASE-17460-branch-1-v5-plusaddendum-v2.patch, HBASE-17460.patch, HBASE-17460_v2.patch, HBASE-17460_v3.patch, HBASE-17460_v4.patch
>
>   Original Estimate: 96h
>  Remaining Estimate: 96h
>
> The enable_table_replication operation is broken for cyclic replication of HBase table as we compare all the properties of column families (including REPLICATION_SCOPE). 
> Below is exactly what happens:
> 1.  Running "enable_table_replication 'table1'  " opeartion on first cluster will set the REPLICATION_SCOPE of all column families to peer id '1'. This will also create a table on second cluster where REPLICATION_SCOPE is still set to peer id '0'.
> 2. Now when we run "enable_table_replication 'table1'" on second cluster, we compare all the properties of table (including REPLICATION_SCOPE_, which obviously is different now. 
> I am proposing a fix for this issue where we should avoid comparing REPLICATION_SCOPE inside HColumnDescriotor::compareTo() method, especially when replication is not already enabled on the desired table.
> I have made that change and it is working. I will submit the patch soon.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)