cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (CASSANDRA-1961) Some kinds of membership changes will still cause overcounts
Date Tue, 11 Jan 2011 23:14:46 GMT

     [ 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.


Mime
View raw message