[
https://issues.apache.org/jira/browse/CASSANDRA-20971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abe Ratnofsky updated CASSANDRA-20971:
--------------------------------------
Change Category: Semantic
Complexity: Normal
Component/s: Local/SSTable
Status: Open (was: Triage Needed)
> CEP-45: Reject untracked SSTables on startup and refresh
> --------------------------------------------------------
>
> Key: CASSANDRA-20971
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20971
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Local/SSTable
> Reporter: Abe Ratnofsky
> Assignee: Abe Ratnofsky
> Priority: Normal
>
> Users expect that they can just throw an SSTable into the right data
> directory and start Cassandra:
> https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/operations/opsBackupSnapshotRestore.html
> But with mutation tracking, we’d break invariants if we served a read from an
> SSTable that wasn’t present in mutation tracking state management. There’s a
> specific import path implemented in CASSANDRA-20383 that accounts for the new
> SSTables, and that’s the path restores should use. But users that are
> expecting to copy a file into a data directory (or run nodetool refresh)
> should be notified that their actions will break invariants.
> Specifically, mutation tracking does a single data read and multiple summary
> reads, and expects that anything not in the summaries is reconciled. If we’re
> adding an SSTable on a single instance and not tracking it in summaries,
> nothing would trigger the propagation of that SSTable to other replicas. In a
> world without mutation tracking, that SSTable would enter the unrepaired set,
> be included in reads at ALL, and eventually make it to other replicas with
> full or incremental repair.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
