If you don't have an explicit goal of dropping compact storage, it's not necessary to as a
prerequisite to upgrading to 4.x+. Development community members recognized that
introducing mandatory schema changes as a prerequisite to upgrading to 4.x would increase
operator + user overhead and limit adoption of the release. To address this, support for
compact storage was reintroduced into 4.x which eliminated the requirement to drop it:
https://issues.apache.org/jira/browse/CASSANDRA-16217 @Matthias, would you be willing to
share the Apache Cassandra version you were running when you observed this behavior and to
file a Jira ticket? – Scott On May 7, 2024, at 7:18 AM, Jeff Jirsa <jji...@gmail.com>
wrote: This sounds a lot like cassandra-13004 which was fixed, but broke data being
read-repaired during an alter statement I suspect it’s not actually that same bug, but may
be close/related. Reproducing it reliably would be a huge help. - Jeff On May 7, 2024, at
1:50 AM, Matthias Pfau via user <user@cassandra.apache.org> wrote: Hi there, we just
ran drop compact storage in order to prepare for the upgrade to version 4. We observed that
column values have been written as null, if they where inserted while the drop compact
storage statement was running. This just happened for the couple seconds the drop compact
storage statement ran. Did anyone else observe this? What are the proposed strategies to
prevent data loss. Best, Matthias
