Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 3 Jun 2016 14:56:59 +0000 (UTC)
From: "Hudson (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12764023.1419859347000.25759.1464965819450@Atlassian.JIRA>
In-Reply-To: <JIRA.12764023.1419859347000@Atlassian.JIRA>
References: <JIRA.12764023.1419859347000@Atlassian.JIRA> <JIRA.12764023.1419859347813@arcas>
Subject: [jira] [Commented] (HBASE-12769) Replication fails to delete all
 corresponding zk nodes when peer is removed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 03 Jun 2016 14:57:01 -0000


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

Hudson commented on HBASE-12769:
--------------------------------

SUCCESS: Integrated in HBase-1.3-IT #689 (See [https://builds.apache.org/job/HBase-1.3-IT/689/])
HBASE-15888 Extend HBASE-12769 for bulk load data replication (ashishsinghi: rev b0e1fdae346b64af4188cf5df29488617753416f)
* hbase-client/src/main/java/org/apache/hadoop/hbase/replication/ReplicationPeersZKImpl.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/util/hbck/ReplicationChecker.java


> Replication fails to delete all corresponding zk nodes when peer is removed
> ---------------------------------------------------------------------------
>
>                 Key: HBASE-12769
>                 URL: https://issues.apache.org/jira/browse/HBASE-12769
>             Project: HBase
>          Issue Type: Improvement
>          Components: Replication
>    Affects Versions: 0.99.2
>            Reporter: Jianwei Cui
>            Assignee: Jianwei Cui
>            Priority: Minor
>             Fix For: 2.0.0, 1.3.0
>
>         Attachments: 12769-branch-1-v5.txt, 12769-v2.txt, 12769-v3.txt, 12769-v4.txt, 12769-v5.txt, 12769-v6.txt, HBASE-12769-trunk-v0.patch, HBASE-12769-trunk-v1.patch
>
>
> When removing a peer, the client side will delete peerId under peersZNode node; then alive region servers will be notified and delete corresponding hlog queues under its rsZNode of replication. However, if there are failed servers whose hlog queues have not been transferred by alive servers(this likely happens if setting a big value to "replication.sleep.before.failover" and lots of region servers restarted), these hlog queues won't be deleted after the peer is removed. I think remove_peer should guarantee all corresponding zk nodes have been removed after it completes; otherwise, if we create a new peer with the same peerId with the removed one, there might be unexpected data to be replicated.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)