[CASSANDRA-16063] Fix user experience when upgrading to 4.0 with compact tables

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.23, 3.11.9, 4.0-beta3, 4.0
• Component/s: Legacy/CQL
• Bug Category: Correctness
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Since Version: 3.0.0

Source Control Link

https://github.com/apache/cassandra/commit/0700dfa0bc26d0758df898101bb595d3ec8d7def

Test and Documentation Plan

https://issues.apache.org/jira/browse/CASSANDRA-16063?focusedCommentId=17201519&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17201519

• Assignee: Ekaterina Dimitrova
• Reporter: Sylvain Lebresne

Authors

Ekaterina Dimitrova

Reviewers

Andres de la Peña, Sylvain Lebresne

• Created: 20/Aug/20 15:09
• Updated: 03/Jan/21 17:02
• Resolved: 13/Oct/20 15:51

Description

The code to handle compact tables has been removed from 4.0, and the intended upgrade path to 4.0 for users having compact tables on 3.x is that they must execute ALTER ... DROP COMPACT STORAGE on all of their compact tables before attempting the upgrade.

Obviously, some users won't read the upgrade instructions (or miss a table) and may try upgrading despite still having compact tables. If they do so, the intent is that the node will not start, with a message clearly indicating the pre-upgrade step the user has missed. The user will then downgrade back the node(s) to 3.x, run the proper ALTER ... DROP COMPACT STORAGE, and then upgrade again.

But while 4.0 does currently fail startup when finding any compact tables with a decent message, I believe the check is done too late during startup.

Namely, that check is done as we read the tables schema, so within Schema.instance.loadFromDisk(). But by then, we've at least called SystemKeyspace.persistLocalMetadata()} and SystemKeyspaceMigrator40.migrate(), which will get into the commit log, and even possibly flush new na format sstables. As a results, a user might not be able to seemlessly restart the node on 3.x (to drop compact storage on the appropriate tables).

Basically, we should make sure the check for compact tables done at 4.0 startup is done as a StartupCheck, before the node does anything.

We should also add a test for this (checking that if you try upgrading to 4.0 with compact storage, you can downgrade back with no intervention whatsoever).

Issue Links

• is related to: CASSANDRA-15897 Dropping compact storage with 2.1-sstables on disk make them unreadable