This sounds most like https://issues.apache.org/jira/browse/CASSANDRA-10371.
Are you on a version that could be affected by this issue? Best, Joel On Thu, Apr 7, 2016 at 11:51 AM, Anubhav Kale <anubhav.k...@microsoft.com> wrote: > Hello, > > > > We removed a DC using instructions from > https://docs.datastax.com/en/cassandra/2.1/cassandra/operations/ops_decomission_dc_t.html > > > > After all nodes were gone, > > > > 1. System.peers don’t have an entry for the nodes that were > removed. (confirmed via a cqlsh query with consistency all) > > 2. Nodetool describecluster don’t show them > > 3. Nodetool gossipinfo show them as “LEFT”. > > > > However, logs continue to spew below and restarting the node doesn’t get > rid of this. I am thinking a rolling restart of all nodes might fix it, but > I am curious as to where is this information still held ? I don’t think > this is causing any badness to the cluster, but I would like to get rid of > this if possible. > > > > INFO [GossipStage:83] 2016-04-07 16:38:07,859 Gossiper.java:998 - > InetAddress /10.1.200.14 is now DOWN > > INFO [GossipStage:83] 2016-04-07 16:38:07,861 StorageService.java:1914 - > Removing tokens[*BLAH*] for /10.1.200.14 > > > > Thanks ! > -- <http://www.datastax.com/> Joel Knighton Cassandra Developer | joel.knigh...@datastax.com <https://www.linkedin.com/company/datastax> <https://www.facebook.com/datastax> <https://twitter.com/datastax> <https://plus.google.com/+Datastax/about> <http://feeds.feedburner.com/datastax> <https://github.com/datastax/>
