incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Wirt" <chris.w...@struq.com>
Subject Rollback question regarding system metadata change
Date Tue, 01 Oct 2013 17:51:06 GMT
Moving back to 1.2.10. What is the procedure roll back from 2.0.1?

 

Changes in the system schema seem to make this quite difficult. 

 

We have:

DC1 - 10 x 1.2.10

DC2 - 4 x 1.2.10

DC3 - 3 x 2.0.1 -> ran this for a couple days and have decided to roll back

 

In my efforts I've now completely taken DC3 offline and already tried:

bootstrapping from empty data dirs.

Using the pre-migrationstable directories to get the old schema back. I
think this just gets overwritten by the newer schema.

 

So, I've dug in a bit and it looks like schema_columns now stores all
'columns' not just the value (non-primary) 'columns' and this is causing me
some issues for my rollback. 1.2.10 does not expecting/handling a null on
the component_index field.

 

So when starting up 1.2.10 with the new schema modified by 2.0.1 I get this
exception on loading my first CF. 

 

'did' happens to be the primary key of the first column family we load,
which contains a null in the component index field.

 

ERROR [main] 2013-10-01 14:55:19,071 CassandraDaemon.java (line 463)
Exception encountered during startup

org.apache.cassandra.db.marshal.MarshalException: unable to make int from
'did'

        at
org.apache.cassandra.db.marshal.Int32Type.fromString(Int32Type.java:87)

        at
org.apache.cassandra.db.marshal.AbstractCompositeType.fromString(AbstractCom
positeType.java:261)

        at
org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.jav
a:230)

        at
org.apache.cassandra.config.CFMetaData.addColumnDefinitionSchema(CFMetaData.
java:1522)

        at
org.apache.cassandra.config.CFMetaData.fromSchema(CFMetaData.java:1454)

        at
org.apache.cassandra.config.KSMetaData.deserializeColumnFamilies(KSMetaData.
java:306)

        at
org.apache.cassandra.config.KSMetaData.fromSchema(KSMetaData.java:287)

        at
org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:154)

        at
org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescripto
r.java:571)

        at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:253)

        at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:4
46)

        at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:489)

Caused by: java.lang.NumberFormatException: For input string: "did"

        at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65
)

        at java.lang.Integer.parseInt(Integer.java:492)

        at java.lang.Integer.parseInt(Integer.java:527)

        at
org.apache.cassandra.db.marshal.Int32Type.fromString(Int32Type.java:83)

 

Is there any easy way back from this?

 

My idea is to modify the schema_columns table to be as it used to prior the
migration. i.e. delete all rows for columns which are part of a primary key.

For obvious reasons I'm a little scared to do this.

 

Can anyone think of anything else I'd better watch out for?

 

Also FYI, We're rolling back due to issues we've experience with the new
HsHa server and after some thorough testing on our side intend on moving
back to 2.*

(I was being a bit cowboy-ish due to pressure to improve performance.)

 

Thanks,

Chris

 

 

 

 

 


Mime
View raw message