[jira] [Created] (CASSANDRA-5914) Failed replace_node bootstrap leaves gossip in weird state ; possible perf problem

["Chris Burroughs (JIRA)" <ji...@apache.org>]

Chris Burroughs created CASSANDRA-5914:
------------------------------------------

             Summary: Failed replace_node bootstrap leaves gossip in weird state ; possible perf problem
                 Key: CASSANDRA-5914
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5914
             Project: Cassandra
          Issue Type: Bug
          Components: Core
         Environment: 1.2.8
            Reporter: Chris Burroughs


A node was down for a week or two due to hardware disk failure.  I tried to use replace_node to bring up a new node on the same physical host with the same IPs.  (rbranson suspected that using the same IP may be issue prone.)  This failed due to "unable to find sufficient sources for streaming range".  However, gossip for the to-be-replaced node was left in a funky state:

{noformat}
/64.215.255.182
  RACK:NOP
  NET_VERSION:6
  HOST_ID:4f3b214b-b03e-46eb-8214-5fab2662a06b
  RELEASE_VERSION:1.2.8
  DC:IAD
  INTERNAL_IP:10.15.2.182
  SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f
  RPC_ADDRESS:0.0.0.0
{noformat}

(See CASSANDRA-5913 for cosmetic issue with nt:status.)

This seems (A) confusing and (B) the failed replace_token correlated with 95th percentile read latency for this cluster going from 8k microseconds to around 200k microseconds (on both DCs in a mutli-dc cluster reading at CL.ONE).  I don't have a good theory for the correlation but performance was bad for over an hour and returned to normal once a successful replace_token was performed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira