Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 10 Feb 2017 00:13:41 +0000 (UTC)
From: "NITIN VERMA (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13034537.1484297434000.43907.1486685621731@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: Fri, 10 Feb 2017 00:13:46 -0000


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

NITIN VERMA commented on HBASE-17460:
-------------------------------------

Thanks Ted!

The code of enabling replication has massive refactoring due to which I have a bad conflict in the branch now. 
The original method which I changed "checkAndSyncTableDescToPeers" has been removed. I am looking at the diffs and will submit another patch.


> 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: replication
>         Attachments: HBASE-17460.patch, HBASE-17460_v2.patch, HBASE-17460_v3.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)