From user-return-36900-apmail-cassandra-user-archive=cassandra.apache.org@cassandra.apache.org Tue Oct 1 17:51:40 2013 Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 896B9FE8C for ; Tue, 1 Oct 2013 17:51:40 +0000 (UTC) Received: (qmail 69659 invoked by uid 500); 1 Oct 2013 17:51:37 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 69266 invoked by uid 500); 1 Oct 2013 17:51:37 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 69258 invoked by uid 99); 1 Oct 2013 17:51:36 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Oct 2013 17:51:36 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of chris.wirt@struq.com designates 209.85.215.169 as permitted sender) Received: from [209.85.215.169] (HELO mail-ea0-f169.google.com) (209.85.215.169) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 01 Oct 2013 17:51:28 +0000 Received: by mail-ea0-f169.google.com with SMTP id k11so3618930eaj.0 for ; Tue, 01 Oct 2013 10:51:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=wyvz98SSA9wSvtwebAC+Oj5iMbL8uGpZBRp7K7c+HyM=; b=ToKEUtl1+cY+R+Nwzmy9eRhOGfzlP/Rt01/Zn5C8CH3Gs6+JYuKRIGgqUNjV2imEEl vw0Znn0xC6jCJrRISJmxxbWYBwtNw1MlXx48lSUFWM0LE6XorutgHVD04/xoKet4pR9w Og12fLKrzitMOrlUf2c5uMyf5mqnsp6eoqvOpbxbIAzDWYxw456l8yW9aPpKE6OewSuW aNPTjNs/AZPoCDFuFq21PETqPTaE8UiQV/nCIIzBxsKCm4Q64QNRphtXj3XIjvvLaKGE ENz3mcANNPiIQLirAKN5Gt/nAxuVeZtu8nhEPYCvuhuCYEcSJql4hNTCLDhrmz9nC/6G m+tQ== X-Gm-Message-State: ALoCoQk25zpF61L8gaIvXsL36AqZPxn5bofXmMir6GG3pHet2edIjUCsrYirPQ5Lgr5+ueuyg7wE X-Received: by 10.14.199.3 with SMTP id w3mr47833161een.33.1380649867605; Tue, 01 Oct 2013 10:51:07 -0700 (PDT) Received: from StevePereiraPC (host81-133-200-21.in-addr.btopenworld.com. [81.133.200.21]) by mx.google.com with ESMTPSA id m54sm15797217eex.2.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 01 Oct 2013 10:51:07 -0700 (PDT) From: "Christopher Wirt" To: Subject: Rollback question regarding system metadata change Date: Tue, 1 Oct 2013 18:51:06 +0100 Message-ID: <01c601cebece$ce0c3510$6a249f30$@struq.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C7_01CEBED7.2FD46DA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6+zorWJ85URke3QCyaq6W+6Tf+9g== Content-Language: en-gb X-Virus-Checked: Checked by ClamAV on apache.org This is a multipart message in MIME format. ------=_NextPart_000_01C7_01CEBED7.2FD46DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_01C7_01CEBED7.2FD46DA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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(Abstract= CompositeType.java:261)

        at = org.apache.cassandra.config.ColumnDefinition.fromSchema(ColumnDefinition.= java:230)

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

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

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

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

        at = org.apache.cassandra.db.DefsTable.loadFromTable(DefsTable.java:154)<= /o:p>

        = at = org.apache.cassandra.config.DatabaseDescriptor.loadSchemas(DatabaseDescri= ptor.java:571)

        at = org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:2= 53)

        at = org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.jav= a:446)

        at = org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:48= 9)

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

 

 

 

 

 

------=_NextPart_000_01C7_01CEBED7.2FD46DA0--