cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yeshvanthni (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-8000) Schema Corruption when 1.2.15->2.0.9 rolling upgrade and in mixed mode
Date Wed, 24 Sep 2014 17:15:33 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-8000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Yeshvanthni updated CASSANDRA-8000:
-----------------------------------
    Description: 
Steps to reproduce:

1. Setup multi-node Cassandra 1.2.15 with following schema 

{code}
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,partitionname) VALUES (now(),dateOf(now()),'user',dateOf(now()),'test');

{code}


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
{code}
CREATE TABLE test (
  testid timeuuid PRIMARY KEY,
  testid timeuuid,
  businesskey timestamp,
  createdby text,
  createdtimestamp timestamp,
  testname text
) ;

{code}
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.




  was:
Steps to reproduce:

1. Setup multi-node Cassandra 1.2.15 with following schema 

{code}
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,partitionname) VALUES (now(),dateOf(now()),'user',dateOf(now()),'test');

{code}


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.





> Schema Corruption when 1.2.15->2.0.9 rolling upgrade and in mixed mode
> ----------------------------------------------------------------------
>
>                 Key: CASSANDRA-8000
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-8000
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Yeshvanthni
>
> Steps to reproduce:
> 1. Setup multi-node Cassandra 1.2.15 with following schema 
> {code}
> 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,partitionname) VALUES
(now(),dateOf(now()),'user',dateOf(now()),'test');
> {code}
> 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
> {code}
> CREATE TABLE test (
>   testid timeuuid PRIMARY KEY,
>   testid timeuuid,
>   businesskey timestamp,
>   createdby text,
>   createdtimestamp timestamp,
>   testname text
> ) ;
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message