[
https://issues.apache.org/jira/browse/CASSANDRA-16434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16434:
-----------------------------------------
Resolution: Invalid
Status: Resolved (was: Triage Needed)
bq. Querying a table from some nodes gave back null results which wasn't
expected.
bq. this problem was solved by running repairs
This indicates your CL wasn't strong enough to contact the replica that had the
data, which brings into question the integrity of the replicas before any
topology movements occurred. If you can provide a reproducible scenario to
make this ticket actionable, please reopen so this can be investigated further.
> Data mismatch across the nodes in the cluster
> ---------------------------------------------
>
> Key: CASSANDRA-16434
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16434
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
> Reporter: Muhammad Junaid Muzammil
> Priority: Normal
>
> Hi,
>
> Recently I have came across one strange issue. On an existing cluster with 12
> nodes, there were new nodes launched replacing the older ones. It was ensured
> that only one node was being added or removed at a time until it comes to
> healthy state. Once the process was completed, we found some data consistency
> issues in the cluster. Querying a table from some nodes gave back null
> results which wasn't expected. Is this expected behaviour? We are running
> Cassandra *3.11.3* version.
> Though this problem was solved by running repairs, but it doesn't sound
> right. There wasn't any strange thing observed from the Cassandra logs (just
> a few timeouts spread over time which is quite normal when a cluster is
> running).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
