hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ashish Singhi (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-17460) enable_table_replication can not perform cyclic replication of a table
Date Mon, 27 Feb 2017 15:58:45 GMT

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

Ashish Singhi commented on HBASE-17460:

bq. Also I am not 100% sure why the check needed in checkAndSyncTableDescToPeers.
If you are not sure then why add it, we can simply solve it by just comparing the HTDs without
replication scope.

If we really require that check then that's a different issue and should be solved as part
of a different jira.

I think we should do the same for master branch also. WDYT [~tedyu] ?

> 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

View raw message