Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Duplicate
-
None
-
None
-
None
-
Normal
Description
Steps to reproduce:
1. Setup multi-node Cassandra 1.2.15 with following schema
CREATE KEYSPACE testkeyspace WITH replication = { 'class': 'SimpleStrategy', 'replication_factor':2 }; USE testkeyspace; CREATE TABLE test ( testid timeuuid PRIMARY KEY, businesskey timestamp, createdby text, createdtimestamp timestamp, testname text ) ; insert into test(testid,businesskey,createdby,createdtimestamp,testname) VALUES (now(),dateOf(now()),'user',dateOf(now()),'test');
2. Roll one node to Cassandra 2.0.9
- Snapshot 1.2.15
- Decommission the old 1.2.15
- Start Cassandra 2.0.9 pointing to the same data folder as 1.2.15
- nodetool upgradesstables
3. Query against 1.2.15 nodes of the cluster with CQLSH
It returns an additional primary key column with null value in it. Describe shows that the table has somehow got the additional column
CREATE TABLE test ( testid timeuuid PRIMARY KEY, testid timeuuid, businesskey timestamp, createdby text, createdtimestamp timestamp, testname text ) ;
Observation:
This could be because of the change in Cassandra 2.x to store all columns including the key columns in schema_columns while earlier key columns were stored schema_columnfamilies.
This blocks rolling upgrades and fails the cluster when in mixed mode.
Attachments
Issue Links
- duplicates
-
CASSANDRA-6695 Don't exchange schema between nodes with different versions (no pull, no push)
- Resolved
- is related to
-
CASSANDRA-6009 Migrate pre-2.0 key/value/column aliases to system.schema_columns
- Resolved