You can also manually add the dropped column to the appropriate table to eliminate the issue. Has to be done by a human, a new cluster would have no way of learning about a dropped column, and the missing metadata cannot be inferred.
On Tue, Feb 19, 2019 at 10:58 AM Elliott Sims <elli...@backblaze.com> wrote: > When a snapshot is taken, it includes a "schema.cql" file. That should be > sufficient to restore whatever you need to restore. I'd argue that neither > automatically resurrecting a dropped table nor silently failing to restore > it is a good behavior, so it's not unreasonable to have the user re-create > the table then choose if they want to re-drop it. > > > On Tue, Feb 19, 2019 at 7:28 AM Hannu Kröger <hkro...@gmail.com> wrote: > >> Hi, >> >> I would like to bring this issue to your attention. >> >> Link to the ticket: >> https://issues.apache.org/jira/browse/CASSANDRA-14336 >> >> Basically if a table contains dropped columns and you try to restore a >> snapshot to a new cluster, that will fail because of an error like >> "java.lang.RuntimeException: Unknown column XXX during deserialization”. >> >> I feel this is quite serious problem for backup and restore functionality >> of Cassandra. You cannot restore a backup to a new cluster if columns have >> been dropped. >> >> There have been other similar tickets that have been apparently closed >> but based on my test with 3.11.4, the issue still persists. >> >> Best Regards, >> Hannu Kröger >> >
