[CASSANDRA-10699] Make schema alterations strongly consistent

• Type: Sub-task
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Legacy/Distributed Metadata
• Assignee: Aleksey Yeschenko
• Reporter: Aleksey Yeschenko

Authors

Aleksey Yeschenko

• Created: 13/Nov/15 15:06
• Updated: 07/Mar/23 10:53

Description

Schema changes do not necessarily commute. This has been the case before CASSANDRA-5202, but now is particularly problematic.

We should employ a strongly consistent protocol instead of relying on marshalling Mutation objects with schema changes.

Issue Links

• incorporates: CASSANDRA-14957 Rolling Restart Of Nodes Causes Dataloss Due To Schema Collision
• is duplicated by: CASSANDRA-10250 Executing lots of schema alters concurrently can lead to dropped alters
• is duplicated by: CASSANDRA-10776 Prepare of statements after table creation fail with unconfigured column family
• is duplicated by: CASSANDRA-11143 Schema changes don't propagate correctly if nodes are down
• relates to: CASSANDRA-10665 Many tests in concurrent_schema_changes_test are failing
• requires: CASSANDRA-13426 Make all DDL statements idempotent and not dependent on global state