You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2011/01/11 03:28:48 UTC
[jira] Created: (CASSANDRA-1961) Some kinds of membership changes
will still cause overcounts
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.
[jira] Commented: (CASSANDRA-1961) Some kinds of membership changes
will still cause overcounts
Posted by "Sylvain Lebresne (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980328#action_12980328 ]
Sylvain Lebresne commented on CASSANDRA-1961:
---------------------------------------------
Yes, I do intend to fix this in CASSANDRA-1938 (by renewing the node uuid each time the node range grows).
> 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.
[jira] Resolved: (CASSANDRA-1961) Some kinds of membership changes
will still cause overcounts
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ 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.