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

Reply via email to