[
https://issues.apache.org/jira/browse/HBASE-17460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873340#comment-15873340
]
Sean Busbey commented on HBASE-17460:
-------------------------------------
I thought the incompatible part of the change was that previously if you had a
table where replication was on for some column families and off for others then
we'd enable it for any where it was off, and now we fail.
{quote}
This patch will have one incompatible behavior change for enable table
replication API.
As per the earlier behavior, If the replication is enabled , user executes the
enable table replication command again and If table descriptor matches , It
will check the replication scope for each column family and if any of the
column family scope is not enabled, it will enable it. otherwise it will do
nothing and final result is success. But as per the patch, it will throw
exception if replication is already enabled.
{quote}
Is the above from [~Bhupendra] not the case, [[email protected]]? If it does
correctly describe the current behavior, I'm fine with a breaking change so
long as 1) we call out the breakage in a release note (the current release note
doesn't sufficiently explain things) and 2) we ensure there is some way to do
the same operation once this change is in place (and also explain such in the
release note). Note that these two things are already needed, since you've
pushed this change to master again.
If we're going use a config to get the old config, that seems a bit heavy for
changing how one invokes a shell command. we'd need to call it out in the help
for the shell command and then I guess we'd expect folks to relaunch the shell
with the modified config? seems like a flag would be better. or perhaps we need
some direct way to say "ensure the replication scope for all the column
families in this table is enabled".
> 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.branch-1.v3.txt, 17460.v5.txt, 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)
