cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "T Jake Luciani (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7601) Data loss after nodetool taketoken
Date Thu, 24 Jul 2014 20:28:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-7601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14073605#comment-14073605
] 

T Jake Luciani commented on CASSANDRA-7601:
-------------------------------------------

I added some debug to the test and here is whats happening for a key that ends up getting
lost:

replicas start as node3 and node1.  after moving node1's tokens to node3 the replicas become
node2 and node3.  Since node3 has no data on it (since it was down for that portion of the
test) we end up having no data on node2 since node1 didn't stream to node2.

> Data loss after nodetool taketoken
> ----------------------------------
>
>                 Key: CASSANDRA-7601
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7601
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core, Tests
>         Environment: Mac OSX Mavericks. Ubuntu 14.04
>            Reporter: Philip Thompson
>            Priority: Minor
>         Attachments: consistent_bootstrap_test.py, taketoken.tar.gz
>
>
> The dtest consistent_bootstrap_test.py:TestBootstrapConsistency.consistent_reads_after_relocate_test
is failing on HEAD of the git branches 2.1 and 2.1.0.
> The test performs the following actions:
> - Create a cluster of 3 nodes
> - Create a keyspace with RF 2
> - Take node 3 down
> - Write 980 rows to node 2 with CL ONE
> - Flush node 2
> - Bring node 3 back up
> - Run nodetool taketoken on node 3 to transfer 80% of node 1's tokens to node 3
> - Check for data loss
> When the check for data loss is performed, only ~725 rows can be read via CL ALL.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message