cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "amorton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-11050) SSTables not loaded after dropping column
Date Tue, 26 Jan 2016 03:42:39 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116610#comment-15116610
] 

amorton commented on CASSANDRA-11050:
-------------------------------------

bq. As a side note, we should really write a dtest for this issue before committing (amorton
would you be up for that?).

[~slebresne] sure thing, is there some docs or example I should check out ? 

bq. So, your option 2 is safe, IMO (special case SchemaKeyspace::calculateSchemaDigest to
ignore dropped_columns).

Thanks [~iamaleksey] will create a new patch with a list for schema hash and a list for everything
else.

[~slebresne] what should I do to make the full change in 4.0, is the trunk at 4.0 ? (sorry
am out of the loop a bit :) )

> 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)

Mime
View raw message