[ https://issues.apache.org/jira/browse/CASSANDRA-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-1961. --------------------------------------- Resolution: Duplicate > Some kinds of membership changes will still cause overcounts > ------------------------------------------------------------ > > Key: CASSANDRA-1961 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1961 > Project: Cassandra > Issue Type: Bug > Components: Core > Reporter: Stu Hood > Fix For: 0.8 > > > Assume replicas A, B, C, and a joining node D, where D is joining between A > and B. The join process will remove C from the replica set, but C will still > be holding counts for those replicas (unless cleanup is run, which we can't > safely assume). If a second membership change occurs such that any of A, B or > D leave the ring, C will be acting as a new member of the replica set, but it > will still be holding its old counts. > The join will: > * BOOTSTRAP - D will bootstrap from the nearest replica, possibly C (but not > necessarily) > The leave will either: > * UNBOOTSTRAP - D will send to C > * RESTORE_REPLICA_COUNT - since D is assumed dead, C will stream from the > nearest replica > Only the AES stream task performs fixups of counters: in all other cases I > think we assume that 'nodetool cleanup' has run, so it is possible to > overcount. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.