[ https://issues.apache.org/jira/browse/CASSANDRA-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13770820#comment-13770820 ]
Guyon Moree commented on CASSANDRA-6053: ---------------------------------------- Just a heads up: I've just removed a broken node using 'nodetool removenode' and encountered the same problem again. The node wasn't removed from the other nodes' system.peers. > 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: Brandon Williams > Attachments: 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 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