[
https://issues.apache.org/jira/browse/CASSANDRA-17777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17777:
--------------------------------------
Fix Version/s: 4.2
Source Control Link:
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=037149377224c5d6854fa4a0cacf44139273bce3
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Skip sstable startup checks for dropped system tables
> -----------------------------------------------------
>
> Key: CASSANDRA-17777
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17777
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Startup and Shutdown
> Reporter: Josh McKenzie
> Assignee: Josh McKenzie
> Priority: Normal
> Fix For: 4.2
>
>
> In CASSANDRA-8049 we changed our behavior to explicitly not startup while
> iterating over the whole data file directory before loading schema. In the
> case where you have (admittedly _very)_ old files left around from dropped
> system tables from old C* versions (think 1.0 era), you can end up with
> clusters that won't start due to what was, at the time, normal operations.
> We should change from hard killing nodes to instead warn operators they have
> leftovers of old system tables that need to be cleaned up. Ideally these
> files would be manually removed by operators before the upgrade to new
> versions however we can't always rely on this so killing nodes on startup for
> this specific case is suboptimal. We certainly still need to log the found
> files to give operators an indication of what needs to be cleaned up.
> While we can't load the schema to make sure all directories are safe, we
> _can_ know which tables exist in the system keyspace so we should be able to
> safely modify this startup check to log rather than kill for system tables
> only.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
