[jira] [Comment Edited] (CASSANDRA-16063) Fix user experience when upgrading to 4.0 with compact tables

["Ekaterina Dimitrova (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-16063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17193913#comment-17193913 ] 

Ekaterina Dimitrova edited comment on CASSANDRA-16063 at 9/11/20, 12:00 AM:
----------------------------------------------------------------------------

So the reason for the  [CommitLog.instance.start()|#L214] being set before the startup checks are
{code:java}
checkSystemKeyspaceState,
checkDatacenter,
checkRack,
checkLegacyAuthTables{code}
and the following dependency:
 * In order to read from the table, we have to first create a {{ColumnFamilyStore.}}
 * {{ColumnFamilyStore}}, in order to function "normally", has to create a memtable.
 * In order to create Memtable, we have to get a current position from commit log.

 

I'll have to think in detail about how we can workaround this but at first glance it doesn't look trivial to me(?) and I am not sure whether it will qualify for beta(?). I will get back to this again tomorrow. 


was (Author: e.dimitrova):
So the reason for the  [CommitLog.instance.start()|#L214] being set before the startup checks are
{code:java}
checkSystemKeyspaceState,
checkDatacenter,
checkRack,
checkLegacyAuthTables{code}
and the following dependency:
 * In order to read from the table, we have to first create a {{ColumnFamilyStore.}}
 * {{ColumnFamilyStore}}, in order to function "normally", has to create a memtable.
 * In order to create Memtable, we have to get a current position from commit log.

 

I'll have to think in detail about how we can workaround this but it doesn't look trivial and not sure whether it will qualify for beta. I will get back to this again tomorrow. 

> Fix user experience when upgrading to 4.0 with compact tables
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-16063
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16063
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/CQL
>            Reporter: Sylvain Lebresne
>            Assignee: Ekaterina Dimitrova
>            Priority: Normal
>             Fix For: 4.0-beta
>
>
> 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()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/CassandraDaemon.java#L241].  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).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org