[
https://issues.apache.org/jira/browse/CASSANDRA-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15112935#comment-15112935
]
Aleksey Yeschenko commented on CASSANDRA-11050:
-----------------------------------------------
[~slebresne] The issue you mention with the second approach is actually not
that terrible. If one drops a column, the schema digest will change, even if
{{dropped_columns}} table itself is not involved in the computation. It will
change simply b/c of a different set of columns in {{system_schema.columns}} -
one fewer if we drop one.
Now, there could be an issue if you drop then recreate a column. Then again,
the timestamps in schema tables will be different in that case, so the change
will still be detected. Unless there is an extremely unlikely clock jump to
that precise previous timestamp?
So, your option 2 is safe, IMO (special case
{{SchemaKeyspace::calculateSchemaDigest}} to ignore {{dropped_columns}}).
> SSTables not loaded after dropping column
> -----------------------------------------
>
> Key: CASSANDRA-11050
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11050
> Project: Cassandra
> Issue Type: Bug
> Components: Distributed Metadata
> Reporter: amorton
> Assignee: amorton
> Attachments: 11050-3.0.patch
>
>
> The {{system_schema.dropped_tables}} table is not flushed when schema is
> updated, this can result in SSTables not being loaded at startup and failure
> to start if the commit log contains mutations with the column.
> Reproduce on cassandra-3.0 branch by starting a node and running following in
> cqlsh:
> {code}
> create keyspace dev WITH replication = {'class':'SimpleStrategy',
> 'replication_factor':1};
> use dev;
> create table foo (
> foo text primary key,
> bar text,
> baz text
> );
> insert into foo (foo, bar, baz) values ('foo','this is bar', 'this is baz');
> alter table foo
> drop baz;
> {code}
> Stop the node and restart, the following errors are raised and the node does
> not start:
> {code}
> ERROR 16:38:19 Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.RuntimeException: Unknown column baz during deserialization
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:331)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:485)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:374)
> ~[main/:na]
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$4.run(SSTableReader.java:533)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_60]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> ~[na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> ~[na:1.8.0_60]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> ...
> ERROR 16:38:19 Exiting due to error while processing commit log during
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
> Unexpected error deserializing mutation; saved to
> /var/folders/r2/rkv1jz3j0j74r9s1zm5xx9wc0000gn/T/mutation5408885979635225676dat.
> This may be caused by replaying a mutation against a table with the same
> name but incompatible schema. Exception follows: java.lang.RuntimeException:
> Unknown column baz during deserialization
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:633)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:556)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:509)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:404)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:151)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189)
> [main/:na]
> at
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:283)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
> [main/:na]
> {code}
> {{dropped_columns}} is not in the list of tables to flush,
> {{SchemaKeyspace.ALL}}.
> It's a simple patch to add it, attached. The fix will need to go to 3.0, 3.1
> and trunk AFAIK
> however this will change the way the schema hash is calculated in
> {{SchemaKeyspace.calculateSchemaDigest()}} It looks like this would cause the
> nodes to announce a new version of the schema on (first) restart.
> I currently donit understand all the implications of changing the schema
> hash, thoughts ?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
