cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anuj (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-8382) Procedure to Change IP Address without Data streaming is Missing in Cassandra Documentation
Date Mon, 29 Dec 2014 06:37:13 GMT

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

Anuj commented on CASSANDRA-8382:
---------------------------------

 As suggested by you, we restarted all Cassandra nodes with new IPs, but nodetool still shows
nodes with old IPs. After restarting a 3 node cluster with new IPs, we saw total of 6 nodes
in Cassandra cluster: 3 nodes with new IPs and 3 nodes with old IPs (? against them). As data
on 3 node cluster hasn't changed at all, we don't want to remove these nodes with old IPs.
Removing each node takes about 12 hrs in our case and is expensive. We want a procedure for
changing IP address where we need not remove nodes with old IPs manually. Also, the procedure
should not cause any downtime. Please suggest.

Nodetool output after restarting 3 node cluster with new IPs:
Here 10.64.8.90,10.44.172.45 and 10.44.172.34 are old IPs whereas 192.168.0.4,192.168.0.5
and 192.168.0.6 are new IPs.

Datacenter: DC1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
State     Address               Load      Tokens Owns    Host ID Rack
DN          10.64.8.90            ?              90dea63f-793b-40be-abf6-cb4a09a27477    
         256         17.2%    RAC1
UN         192.168.0.4         212.98 KB             64f51130-ae48-4fe1-84ec-70a7e3f8fb3e
               256         17.3%    RAC1
DN          10.44.172.45       ?              9f4d33a3-1d17-4f78-b37e-de272fea72dd       
      256         17.9%    RAC1
UN         192.168.0.6         194.32 KB             d83e6e06-690b-4733-a134-ebd721da5ecd
           256         16.4%    RAC1
DN          10.44.172.34       ?              6d3cf257-501f-4d0a-b894-ef9bbf3647ee       
       256         16.2%    RAC1
UN         192.168.0.5         194.3 KB               34db82f6-5176-4d72-8446-2d9c607d0453
             256         15.0%    RAC1

Procedure followed for changing IPs:
1. Stop all Cassandra nodes
2. Update cassandra.yaml with seeds and listen_address as per new IPs
3. Update cassandra-topology.properties with new IPs
4. Restart Cassandra nodes.



> Procedure to Change IP Address without Data streaming is Missing in Cassandra Documentation
> -------------------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-8382
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8382
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Documentation & website
>         Environment: Red Hat Linux , Cassandra 2.0.3
>            Reporter: Anuj
>
> Use Case: 
> We have a Geo-Red setup with 2 DCs (DC1 and DC2) having 3 nodes each. Listen address
and seeds of all nodes are Public IPs while rpc addresses are private IPs.  Now, we want to
decommission a DC2 and change public IPs in listen address/seeds of DC1 nodes to private IPs
as it will be a single DC setup.
> Issue: 
> Cassandra doesn’t provide any standard procedure for changing IP address of nodes in
a cluster. We can bring down nodes, one by one, change their IP address and perform the procedure
mentioned in “ Replacing a Dead Node” at http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html
 by mentioning public IP of the node in replace_address option. But procedure recommends that
you must set the auto_bootstrap option to true.  We don’t want any bootstrap and data streaming
to happen as data is already there on nodes. So, our questions is : What’s the standard
procedure for changing IP address of Cassandra nodes while making sure that no data streaming
occurs and gossip state is not corrupted.
> We are using vnodes.



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

Mime
View raw message