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

Hadoop QA commented on HBASE-12769:
-----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12769179/12769-v6.txt
  against master branch at commit 210c3dd93748b5de65301f2cca2342f36e169b78.
  ATTACHMENT ID: 12769179

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:green}+1 tests included{color}.  The patch appears to include 12 new 
or modified tests.

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/16256//console

This message is automatically generated.

> 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-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)

Reply via email to