cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Branimir Lambov (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-10238) Consolidating racks violates the RF contract
Date Thu, 17 Sep 2015 08:46:47 GMT


Branimir Lambov commented on CASSANDRA-10238:

Is this a sufficient solution? Switching racks can easily cause data to need to move from
one replica to another (e.g. second replica changes from being on a different rack from first
to being on the same in a multi-rack DC). How do we trigger streaming of such data?

Also, {{TokenMetadata.updateTopology}} (both versions) should include a call to {{invalidateCachedRings()}}
to make sure replication strategies do not use stale data; this is already done by {{(Gossiping)PropertyFileSnitch}}
for any local change, but invalidation should also be done on gossiped changes. The {{updateTopology}}
call in the snitches belongs within {{reloadConfiguration}} at the existing cache invalidation

While we are in this, we should also either remove {{StorageService.updateSnitch}} (it does
not appear to be used) or fix the same issue there.

> Consolidating racks violates the RF contract
> --------------------------------------------
>                 Key: CASSANDRA-10238
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Brandon Williams
>            Assignee: Stefania
>            Priority: Critical
>             Fix For: 2.0.17, 3.0.0 rc1, 2.1.10, 2.2.2
> I have only tested this on 2.0 so far, but I suspect it will affect multiple versions.
> Repro:
> * create a datacenter with rf>1
> * create more than one rack in this datacenter
> * consolidate these racks into 1
> * getendpoints will reveal the RF in practice is 1, even though other tools will report
the original RF that was set
> Restarting Cassandra will resolve this.

This message was sent by Atlassian JIRA

View raw message