[
https://issues.apache.org/jira/browse/CASSANDRA-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14582302#comment-14582302
]
Kishan Karunaratne edited comment on CASSANDRA-9584 at 6/11/15 6:07 PM:
------------------------------------------------------------------------
After changing the default connect port (7199) to the Windows listen port
(7100), I was able to use nodetool from the CLI directly to decommission the
first node, 127.0.0.1. While CCM's node status was not updated, I was able to
verify via nodetool status that the node no longer exists in the ring. However,
the Java process still exists for the decommissioned node.
Furthermore, I'm still able to query the decommissioned node through both CCM:
{noformat}
PS C:\Users\Administrator> ccm node1 nodetool status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
Rack
UN 127.0.0.2 62.48 KB 1 ?
4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a rack1
UN 127.0.0.3 62.48 KB 1 ?
d8dd050d-cf88-4c45-97c4-f785db3a1c56 rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
PS C:\Users\Administrator> ccm node1 ring
Starting NodeTool
Datacenter: datacenter1
==========
Address Rack Status State Load Owns Token
3074457345618258602
127.0.0.2 rack1 Up Normal 62.48 KB ?
-3074457345618258603
127.0.0.3 rack1 Up Normal 62.48 KB ?
3074457345618258602
Note: Non-system keyspaces don't have the same replication settings,
effective ownership information is meaningless
{noformat}
and through nodetool directly:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
Rack
UN 127.0.0.2 62.48 KB 1 ?
4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a rack1
UN 127.0.0.3 62.48 KB 1 ?
d8dd050d-cf88-4c45-97c4-f785db3a1c56 rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 ring
Starting NodeTool
Datacenter: datacenter1
==========
Address Rack Status State Load Owns Token
3074457345618258602
127.0.0.2 rack1 Up Normal 62.48 KB ?
-3074457345618258603
127.0.0.3 rack1 Up Normal 62.48 KB ?
3074457345618258602
Note: Non-system keyspaces don't have the same replication settings,
effective ownership information is meaningless
{noformat}
I wasn't able to decommssion other nodes as I get a:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.2
decommission
nodetool: Failed to connect to '127.0.0.2:7100' - ConnectException: 'Connection
refused: connect'.
{noformat}
was (Author: kishkaru):
After changing the default connect port (7199) to the Windows listen port
(7100), I was able to use nodetool from the CLI directly to decommission the
first node, 127.0.0.1. While CCM's node status was not updated, I was able to
verify via nodetool status that the node no longer exists in the ring. However,
the Java process still exists for the decommissioned node.
Furthermore, I'm still able to query the decommissioned node through both CCM:
{noformat}
PS C:\Users\Administrator> ccm node1 nodetool status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
Rack
UN 127.0.0.2 62.48 KB 1 ?
4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a rack1
UN 127.0.0.3 62.48 KB 1 ?
d8dd050d-cf88-4c45-97c4-f785db3a1c56 rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
PS C:\Users\Administrator> ccm node1 ring
Starting NodeTool
Datacenter: datacenter1
==========
Address Rack Status State Load Owns Token
3074457345618258602
127.0.0.2 rack1 Up Normal 62.48 KB ?
-3074457345618258603
127.0.0.3 rack1 Up Normal 62.48 KB ?
3074457345618258602
Note: Non-system keyspaces don't have the same replication settings,
effective ownership information is meaningless
{noformat}
and through nodetool directly:
{noformat}
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 status
Starting NodeTool
Datacenter: datacenter1
========================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID
Rack
UN 127.0.0.2 62.48 KB 1 ?
4cb1b80e-a83e-4754-9d1c-80afcfe1cc4a rack1
UN 127.0.0.3 62.48 KB 1 ?
d8dd050d-cf88-4c45-97c4-f785db3a1c56 rack1
Note: Non-system keyspaces don't have the same replication settings, effective
ownership information is meaningless
PS C:\Users\jenkins\git\cassandra\bin> .\nodetool -p 7100 -h 127.0.0.1 ring
Starting NodeTool
Datacenter: datacenter1
==========
Address Rack Status State Load Owns Token
3074457345618258602
127.0.0.2 rack1 Up Normal 62.48 KB ?
-3074457345618258603
127.0.0.3 rack1 Up Normal 62.48 KB ?
3074457345618258602
Note: Non-system keyspaces don't have the same replication settings,
effective ownership information is meaningless
{noformat}
I wasn't able to decommssion other nodes as I get a:
{noformat}
nodetool: Failed to connect to '127.0.0.2:7100' - ConnectException: 'Connection
refused: connect'.
{noformat}
> Decommissioning a node on Windows sends the wrong schema change event
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-9584
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9584
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.2.0-rc1 | python-driver 2.6.0-rc1 | Windows Server
> 2012 R2 64-bit
> Reporter: Kishan Karunaratne
> Assignee: Joshua McKenzie
> Fix For: 2.2.x
>
>
> Decommissioning a node on Windows sends the wrong schema change event:
> {noformat}
> cassandra.connection: DEBUG: Message pushed from server:
> <EventMessage(event_type=u'STATUS_CHANGE', trace_id=None, event
> _args={'change_type': u'DOWN', 'address': ('127.0.0.2', 9042)}, stream_id=-1)>
> {noformat}
> On Linux I get the correct event:
> {noformat}
> cassandra.connection: DEBUG: Message pushed from server:
> <EventMessage(event_type=u'TOPOLOGY_CHANGE', trace_id=None,
> event_args={'change_type': u'REMOVED_NODE', 'address': ('127.0.0.2', 9042)},
> stream_id=-1)>
> {noformat}
> We are using ccmlib node.py.decommission() which calls nodetool decommission:
> {noformat}
> def decommission(self):
> self.nodetool("decommission")
> self.status = Status.DECOMMISIONNED
> self._update_config()
> {noformat}
> Interestingly, it does seem to work (correctly?) on CCM CLI:
> {noformat}
> PS C:\Users\Administrator> ccm status
> Cluster: '2.2'
> --------------
> node1: UP
> node3: UP
> node2: UP
> PS C:\Users\Administrator> ccm node1 ring
> Starting NodeTool
> Datacenter: datacenter1
> ==========
> Address Rack Status State Load Owns
> Token
>
> 3074457345618258602
> 127.0.0.1 rack1 Up Normal 62.43 KB ?
> -9223372036854775808
> 127.0.0.2 rack1 Up Normal 104.87 KB ?
> -3074457345618258603
> 127.0.0.3 rack1 Up Normal 83.67 KB ?
> 3074457345618258602
> Note: Non-system keyspaces don't have the same replication settings,
> effective ownership information is meaningless
> PS C:\Users\Administrator> ccm node2 decommission
> PS C:\Users\Administrator> ccm status
> Cluster: '2.2'
> --------------
> node1: UP
> node3: UP
> node2: DECOMMISIONNED
> PS C:\Users\Administrator> ccm node1 ring
> Starting NodeTool
> Datacenter: datacenter1
> ==========
> Address Rack Status State Load Owns
> Token
>
> 3074457345618258602
> 127.0.0.1 rack1 Up Normal 67.11 KB ?
> -9223372036854775808
> 127.0.0.3 rack1 Up Normal 88.35 KB ?
> 3074457345618258602
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
