[
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.
thanks
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
Demai
> [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
(v6.1#6144)
