[
https://issues.apache.org/jira/browse/CASSANDRA-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17149210#comment-17149210
]
Sylvain Lebresne commented on CASSANDRA-15897:
----------------------------------------------
The problem here is that the 2.X sstables layout is that of the "compact"
table, and can't be read properly post-DROP COMPACT unless we still remember
the table "was" compact.
Overall, I can see only 2 main options:
# we remember somehow that a table "was" compact, even after a {{DROP COMPACT
STORAGE}}. The code reading legacy sstables could then use the old compact
version of the table metadata, and I think this would work. One way to preserve
this information could be that, instead of dropping the COMPOUND/DENSE flags
when {{DROP COMPACT STORAGE}} is used, we'd preserve those but add a new
{{COMPACT_STORAGE_DROPPED}} flag. I think doing so would be relatively simple
code-wise, and preserving the information that a table _was_ compact
internally, at least until 4.0 (which can clean all that up) almost feel like a
good idea (I doubt many people have tried {{DROP COMPACT STORAGE}} yet, but
some will have to to upgrade to 4.0 and keeping this info may help diagnose
issues along the way). The downsides I can see however are:
#* adding a flag impacts drivers, at least when they read the schema (not that
it completely break driver versions that won't know about the flag...).
#* DROP COMPACT STORAGE has been released a while ago already and this wouldn't
be retroactive. Not sure it's a big deal, but I may not have think it through.
# we don't "allow" DROP COMPACT STORAGE until all 2.x sstables have been
upgraded. Now, if we could easily reject DROP COMPACT STORAGE requests until
all sstables are in the 3.x format, I probably wouldn't even suggest the first
option above. But it's actually not trivial, because when a coordinator receive
such requests, it has no way to know what sstable formats the other nodes have.
So I guess there is 2 sub-options:
## we clearly document that one should upgrade sstables on all nodes before
trying DROP COMPACT STORAGE, but don't do more than that. Not amazing, but
certainly the simplest option.
## we start having each node gossip, say, the lowest sstable format version it
has locally, so we can properly reject DROP COMPACT STORAGE until it's safe. My
main personal caveat here is that I'm always a tad nervous with adding things
to Gossip in a minor. But I _think_ it's pretty safe to do so.
I'm happy to implement any of those solution we prefer (and of course, there
may be better suggestions), but we need to pick. Personally, I'd prefer
avoiding 2.1 unless the other options prove more complex than I think, but I'm
not 100% sure between 1 and 2.2. Maybe 2.2 because it has not externally
visible impact on drivers.
Other opinions (going to arbitrarily ping [~marcuse], [~ifesdjeen] and
[~aleksey] as people knowledgeable of COMPACT STORAGE but welcoming every
opinion)?
> Dropping compact storage with 2.1-sstables on disk make them unreadable
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-15897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15897
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Sylvain Lebresne
> Priority: Normal
>
> Test reproducing:
> https://github.com/krummas/cassandra/commits/marcuse/dropcompactstorage
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
