Details
-
Bug
-
Status: Review In Progress
-
Normal
-
Resolution: Unresolved
-
None
-
Availability - Process Crash
-
Normal
-
Normal
-
User Report
-
All
-
None
-
Description
We don't force order in the execution of replayed mutations and hence a mutation can move ahead of or behind a schema change it relies on (e.g. added/removed column), which can then cause it to be rejected because of a schema mismatch.
To fix this, we need to identify schema mutations and make sure the log enforces their execution after all previous mutations have completed and before anything following is started.
Schema mutations are flushed after being applied, so this only would be a problem if the node abruptly stops before flushing the schema mutation.
Attachments
Issue Links
- Testing discovered
-
CASSANDRA-17335 Fix race condition bug during local session repair
- Resolved