hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Demai Ni (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-4654) [replication] Add a check to make sure we don't replicate to ourselves
Date Fri, 08 Nov 2013 17:26:23 GMT

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

Demai Ni commented on HBASE-4654:

hi, folks,

I encountered the same problem last week. 
 email@dev list :http://mail-archives.apache.org/mod_mbox/hbase-dev/201310.mbox/%3CCAOEq2C5g7-8MfUBSdzeTgzNFJU6pkP3cMY_62N18z3pRXe2SMw%40mail.gmail.com%3E

My case was (on hbase 0.94.9) that a zoo.cfg was put under ./hbase/conf. 

I was thinking about to open a jira for the sanity check (exactly the same idea), and glad
to find this jira before opening a dup.  

Just curious that why this jira hasn't been pushed into trunk and 0.94 yet since no strong
objection in the comments. Well, understand that this is a rare case, but a couple line of
code can save someone(like me) several hours of debugging, which sounds a good idea. 

The jira is still unassigned. I can do some testing and upload an up-to-date patch (both trunk
and 0.94) if everyone is busy. 


P.S. per the comments about checking 'addPeer'. I tried it(add_peer with zookeeper info of
the master cluster), which won't cause the UUID case in replicateSource. So far, the only
case I am aware of is the one reported with incorrect zoo.cfg


> [replication] Add a check to make sure we don't replicate to ourselves
> ----------------------------------------------------------------------
>                 Key: HBASE-4654
>                 URL: https://issues.apache.org/jira/browse/HBASE-4654
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.90.4
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.92.3
>         Attachments: 4654-trunk.txt
> It's currently possible to add a peer for replication and point it to the local cluster,
which I believe could very well happen for those like us that use only one ZK ensemble per
DC so that only the root znode changes when you want to set up replication intra-DC.
> I don't think comparing just the cluster ID would be enough because you would normally
use a different one for another cluster and nothing will block you from pointing elsewhere.
> Comparing the ZK ensemble address doesn't work either when you have multiple DNS entries
that point at the same place.
> I think this could be resolved by looking up the master address in the relevant znode
as it should be exactly the same thing in the case where you have the same cluster.

This message was sent by Atlassian JIRA

View raw message