[
https://issues.apache.org/jira/browse/CASSANDRA-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-6053:
-----------------------------------
Attachment: 6053-v1.patch
The problem was that state changes for the removed node were being handled
after the system.peers row was deleted. These state changes would result in
update to the system.peers row, partially reviving it.
6053-v1.patch (and
[branch|https://github.com/thobbs/cassandra/tree/CASSANDRA-6053]) avoids
updating the system.peers table if the node is unknown or is in one of the
"dead" states and adds some basic unit test coverage.
> system.peers table not updated after decommissioning nodes in C* 2.0
> --------------------------------------------------------------------
>
> Key: CASSANDRA-6053
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6053
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Datastax AMI running EC2 m1.xlarge instances
> Reporter: Guyon Moree
> Assignee: Tyler Hobbs
> Attachments: 6053-v1.patch, peers
>
>
> After decommissioning my cluster from 20 to 9 nodes using opscenter, I found
> all but one of the nodes had incorrect system.peers tables.
> This became a problem (afaik) when using the python-driver, since this
> queries the peers table to set up its connection pool. Resulting in very slow
> startup times, because of timeouts.
> The output of nodetool didn't seem to be affected. After removing the
> incorrect entries from the peers tables, the connection issues seem to have
> disappeared for us.
> Would like some feedback on if this was the right way to handle the issue or
> if I'm still left with a broken cluster.
> Attached is the output of nodetool status, which shows the correct 9 nodes.
> Below that the output of the system.peers tables on the individual nodes.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
