[CASSANDRA-10250] Executing lots of schema alters concurrently can lead to dropped alters

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Duplicate
• Severity: Normal
• Since Version: 2.0.0
• Assignee: Unassigned
• Reporter: Andrew Hust

Reviewers

Aleksey Yeschenko

• Created: 02/Sep/15 04:20
• Updated: 16/Apr/19 09:30
• Resolved: 13/Nov/15 15:10

Description

A recently added dtest has been flapping on cassci and has exposed an issue with running lots of schema alterations concurrently. The failures occur on healthy clusters but seem to occur at higher rates when 1 node is down during the alters.

The test executes the following – 440 total commands:

• Create 20 new tables
• Drop 7 columns one at time across 20 tables
• Add 7 columns one at time across 20 tables
• Add one column index on each of the 7 columns on 20 tables

Outcome is random. Majority of the failures are dropped columns still being present, but new columns and indexes have been observed to be incorrect. The logs are don’t have exceptions and the columns/indexes that are incorrect don’t seem to follow a pattern. Running a nodetool describecluster on each node shows the same schema id on all nodes.

Attached is a python script extracted from the dtest. Running against a local 3 node cluster will reproduce the issue (with enough runs – fails ~20% on my machine).

Also attached is the node logs from a run with when a dropped column (alter_me_7 table, column s1) is still present. Checking the system_schema tables for this case shows the s1 column in both the columns and drop_columns tables.

This has been flapping on cassci on versions 2+ and doesn’t seem to be related to changes in 3.0. More testing needs to be done though.

//cc enigmacurry

Issue Links

• duplicates: CASSANDRA-10699 Make schema alterations strongly consistent
• duplicates: CASSANDRA-9425 Make node-local schema fully immutable
• is duplicated by: CASSANDRA-10665 Many tests in concurrent_schema_changes_test are failing