[
https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493955#comment-17493955
]
Aleksey Yeschenko commented on CASSANDRA-16878:
-----------------------------------------------
bq. If a mutation is added to the commit log, it means it has passed the
validation, which indicates the required schema change is present, and the
corresponding mutations should be allocated earlier
I'm not sure that is always the case. Consider the following scenario:
0. table1 exists
1. A mutation m1 for table1 comes in and gets validated for the commit log
write successfully
2. {{DROP TABLE table1}} happens, gets written to the commit log before m1 gets
written to the commit log
3. Mutation m1 is written to the commit log
If you replay these in commit log order, you won't be able to deserialize
mutation m1, as the table will have been dropped.
Only ensuring order on one side of the process is a half-measure that will help
in some cases and hurt in others. But, again, I might be missing something.
> Race in commit log replay can cause rejected mutations
> ------------------------------------------------------
>
> Key: CASSANDRA-16878
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16878
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
> Reporter: Andres de la Peña
> Assignee: Andres de la Peña
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> 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|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271]
> after being applied, so this only would be a problem if the node abruptly
> stops before flushing the schema mutation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
