You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Bryan Cheng <br...@blockcypher.com> on 2015/12/03 02:30:47 UTC
Re: Issues on upgrading from 2.2.3 to 3.0
Has your configuration changed?
This is a new check- https://issues.apache.org/jira/browse/CASSANDRA-10242.
It seems likely either your snitch changed, your properties changed, or
something caused Cassandra to think one of the two happened...
What's your node layout?
On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com> wrote:
> Hello all,
>
> I had 2 of my systems upgraded to 3.0 from the same previous version.
>
> The first cluster seem to be fine.
>
> But the second, each node starts and then fails.
>
> On the log I have the following on all of them:
>
> INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 -
> Initializing system_schema.keyspaces
> INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 -
> Initializing system_schema.tables
> INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 -
> Initializing system_schema.columns
> INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 -
> Initializing system_schema.triggers
> INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 -
> Initializing system_schema.dropped_columns
> INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 -
> Initializing system_schema.views
> INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 -
> Initializing system_schema.types
> INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 -
> Initializing system_schema.functions
> INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 -
> Initializing system_schema.aggregates
> INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 -
> Initializing system_schema.indexes
> ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot
> start node if snitch's rack differs from previous rack. Please fix the
> snitch or decommission and rebootstrap this node.
>
> It asks to "Please fix the snitch or decommission and rebootstrap this
> node"
>
> If none of the nodes can go up, how can I decommission all of them?
>
> Doesn't make sense.
>
> Any suggestions?
>
> Thanks,
>
> C.
>
RE: Issues on upgrading from 2.2.3 to 3.0
Posted by SE...@homedepot.com.
Thank you! I made my comments in the JIRA.
Sean Durity – Lead Cassandra Admin
From: Jeff Jirsa [mailto:jeff.jirsa@crowdstrike.com]
Sent: Monday, December 14, 2015 3:25 PM
To: user@cassandra.apache.org
Subject: Re: Issues on upgrading from 2.2.3 to 3.0
https://issues.apache.org/jira/browse/CASSANDRA-10745
GPFS seems like it SHOULD be easier to package and distribute in most use cases…
From: "SEAN_R_DURITY@homedepot.com<ma...@homedepot.com>"
Reply-To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
Date: Monday, December 14, 2015 at 11:56 AM
To: "user@cassandra.apache.org<ma...@cassandra.apache.org>"
Subject: RE: Issues on upgrading from 2.2.3 to 3.0
Is there a JIRA for the discussion of dropping PropertyFileSnitch? That is all that we use, and it is much easier to package and distribute than GossipingPropertyFileSnitch. I would vote against dropping the more useful PropertyFileSnitch.
Sean Durity – Lead Cassandra Admin
From: Paulo Motta [mailto:pauloricardomg@gmail.com]
Sent: Thursday, December 03, 2015 7:04 AM
To: user@cassandra.apache.org<ma...@cassandra.apache.org>
Subject: Re: Issues on upgrading from 2.2.3 to 3.0
You can migrate from the RackInferingSnitch to PropertiesFileSnitch by populating the cassandra-topology.properties with the same rack/dc assignments of the previous snitch (what you can't change is the assignment, but you can change snitches if you maintain the same assignments as before).
For example, if you were using using the RackInferingSnitch before, an equivalent configuration on the PropertiesFileSnitch is:
IP=DC:RACK
175.56.12.105=56:12 (3rd octet is DC, 2nd is RACK on RackInferingSnitch)
175.56.13.200=56:13
175.54.35.197=54:35
120.54.24.101=54:24
There is a chance the PropertiesFileSnitch is deprecated in the near future, so it's preferable to use the GossipingPropertyFileSnitch which is also simpler to configure.
2015-12-02 23:30 GMT-08:00 Carlos A <na...@gmail.com>>:
Bryan, thanks for replying. I had that figured out already few days ago. The issue was that the snitch method was also changed on the configuration hence the problem.
Now, if you change from rackInferingSnitch to PropertiesFileSnitch it will not run as the data has to be migrated. Is that correct? Or do you have the change the replication class on the keyspace?
Putting back to rackInferingSnitch worked just fine.
On Wed, Dec 2, 2015 at 6:30 PM, Bryan Cheng <br...@blockcypher.com>> wrote:
Has your configuration changed?
This is a new check- https://issues.apache.org/jira/browse/CASSANDRA-10242. It seems likely either your snitch changed, your properties changed, or something caused Cassandra to think one of the two happened...
What's your node layout?
On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com>> wrote:
Hello all,
I had 2 of my systems upgraded to 3.0 from the same previous version.
The first cluster seem to be fine.
But the second, each node starts and then fails.
On the log I have the following on all of them:
INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 - Initializing system_schema.keyspaces
INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 - Initializing system_schema.tables
INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 - Initializing system_schema.columns
INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 - Initializing system_schema.triggers
INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 - Initializing system_schema.dropped_columns
INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 - Initializing system_schema.views
INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 - Initializing system_schema.types
INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 - Initializing system_schema.functions
INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 - Initializing system_schema.aggregates
INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 - Initializing system_schema.indexes
ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot start node if snitch's rack differs from previous rack. Please fix the snitch or decommission and rebootstrap this node.
It asks to "Please fix the snitch or decommission and rebootstrap this node"
If none of the nodes can go up, how can I decommission all of them?
Doesn't make sense.
Any suggestions?
Thanks,
C.
________________________________
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
________________________________
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
Re: Issues on upgrading from 2.2.3 to 3.0
Posted by Jeff Jirsa <je...@crowdstrike.com>.
https://issues.apache.org/jira/browse/CASSANDRA-10745
GPFS seems like it SHOULD be easier to package and distribute in most use cases…
From: "SEAN_R_DURITY@homedepot.com"
Reply-To: "user@cassandra.apache.org"
Date: Monday, December 14, 2015 at 11:56 AM
To: "user@cassandra.apache.org"
Subject: RE: Issues on upgrading from 2.2.3 to 3.0
Is there a JIRA for the discussion of dropping PropertyFileSnitch? That is all that we use, and it is much easier to package and distribute than GossipingPropertyFileSnitch. I would vote against dropping the more useful PropertyFileSnitch.
Sean Durity – Lead Cassandra Admin
From: Paulo Motta [mailto:pauloricardomg@gmail.com]
Sent: Thursday, December 03, 2015 7:04 AM
To: user@cassandra.apache.org
Subject: Re: Issues on upgrading from 2.2.3 to 3.0
You can migrate from the RackInferingSnitch to PropertiesFileSnitch by populating the cassandra-topology.properties with the same rack/dc assignments of the previous snitch (what you can't change is the assignment, but you can change snitches if you maintain the same assignments as before).
For example, if you were using using the RackInferingSnitch before, an equivalent configuration on the PropertiesFileSnitch is:
IP=DC:RACK
175.56.12.105=56:12 (3rd octet is DC, 2nd is RACK on RackInferingSnitch)
175.56.13.200=56:13
175.54.35.197=54:35
120.54.24.101=54:24
There is a chance the PropertiesFileSnitch is deprecated in the near future, so it's preferable to use the GossipingPropertyFileSnitch which is also simpler to configure.
2015-12-02 23:30 GMT-08:00 Carlos A <na...@gmail.com>:
Bryan, thanks for replying. I had that figured out already few days ago. The issue was that the snitch method was also changed on the configuration hence the problem.
Now, if you change from rackInferingSnitch to PropertiesFileSnitch it will not run as the data has to be migrated. Is that correct? Or do you have the change the replication class on the keyspace?
Putting back to rackInferingSnitch worked just fine.
On Wed, Dec 2, 2015 at 6:30 PM, Bryan Cheng <br...@blockcypher.com> wrote:
Has your configuration changed?
This is a new check- https://issues.apache.org/jira/browse/CASSANDRA-10242. It seems likely either your snitch changed, your properties changed, or something caused Cassandra to think one of the two happened...
What's your node layout?
On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com> wrote:
Hello all,
I had 2 of my systems upgraded to 3.0 from the same previous version.
The first cluster seem to be fine.
But the second, each node starts and then fails.
On the log I have the following on all of them:
INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 - Initializing system_schema.keyspaces
INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 - Initializing system_schema.tables
INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 - Initializing system_schema.columns
INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 - Initializing system_schema.triggers
INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 - Initializing system_schema.dropped_columns
INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 - Initializing system_schema.views
INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 - Initializing system_schema.types
INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 - Initializing system_schema.functions
INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 - Initializing system_schema.aggregates
INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 - Initializing system_schema.indexes
ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot start node if snitch's rack differs from previous rack. Please fix the snitch or decommission and rebootstrap this node.
It asks to "Please fix the snitch or decommission and rebootstrap this node"
If none of the nodes can go up, how can I decommission all of them?
Doesn't make sense.
Any suggestions?
Thanks,
C.
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
RE: Issues on upgrading from 2.2.3 to 3.0
Posted by SE...@homedepot.com.
Is there a JIRA for the discussion of dropping PropertyFileSnitch? That is all that we use, and it is much easier to package and distribute than GossipingPropertyFileSnitch. I would vote against dropping the more useful PropertyFileSnitch.
Sean Durity – Lead Cassandra Admin
From: Paulo Motta [mailto:pauloricardomg@gmail.com]
Sent: Thursday, December 03, 2015 7:04 AM
To: user@cassandra.apache.org
Subject: Re: Issues on upgrading from 2.2.3 to 3.0
You can migrate from the RackInferingSnitch to PropertiesFileSnitch by populating the cassandra-topology.properties with the same rack/dc assignments of the previous snitch (what you can't change is the assignment, but you can change snitches if you maintain the same assignments as before).
For example, if you were using using the RackInferingSnitch before, an equivalent configuration on the PropertiesFileSnitch is:
IP=DC:RACK
175.56.12.105=56:12 (3rd octet is DC, 2nd is RACK on RackInferingSnitch)
175.56.13.200=56:13
175.54.35.197=54:35
120.54.24.101=54:24
There is a chance the PropertiesFileSnitch is deprecated in the near future, so it's preferable to use the GossipingPropertyFileSnitch which is also simpler to configure.
2015-12-02 23:30 GMT-08:00 Carlos A <na...@gmail.com>>:
Bryan, thanks for replying. I had that figured out already few days ago. The issue was that the snitch method was also changed on the configuration hence the problem.
Now, if you change from rackInferingSnitch to PropertiesFileSnitch it will not run as the data has to be migrated. Is that correct? Or do you have the change the replication class on the keyspace?
Putting back to rackInferingSnitch worked just fine.
On Wed, Dec 2, 2015 at 6:30 PM, Bryan Cheng <br...@blockcypher.com>> wrote:
Has your configuration changed?
This is a new check- https://issues.apache.org/jira/browse/CASSANDRA-10242. It seems likely either your snitch changed, your properties changed, or something caused Cassandra to think one of the two happened...
What's your node layout?
On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com>> wrote:
Hello all,
I had 2 of my systems upgraded to 3.0 from the same previous version.
The first cluster seem to be fine.
But the second, each node starts and then fails.
On the log I have the following on all of them:
INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 - Initializing system_schema.keyspaces
INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 - Initializing system_schema.tables
INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 - Initializing system_schema.columns
INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 - Initializing system_schema.triggers
INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 - Initializing system_schema.dropped_columns
INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 - Initializing system_schema.views
INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 - Initializing system_schema.types
INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 - Initializing system_schema.functions
INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 - Initializing system_schema.aggregates
INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 - Initializing system_schema.indexes
ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot start node if snitch's rack differs from previous rack. Please fix the snitch or decommission and rebootstrap this node.
It asks to "Please fix the snitch or decommission and rebootstrap this node"
If none of the nodes can go up, how can I decommission all of them?
Doesn't make sense.
Any suggestions?
Thanks,
C.
________________________________
The information in this Internet Email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this Email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this Email are subject to the terms and conditions expressed in any applicable governing The Home Depot terms of business or client engagement letter. The Home Depot disclaims all responsibility and liability for the accuracy and content of this attachment and for any damages or losses arising from any inaccuracies, errors, viruses, e.g., worms, trojan horses, etc., or other items of a destructive nature, which may be contained in this attachment and shall not be liable for direct, indirect, consequential or special damages in connection with this e-mail message or its attachment.
Re: Issues on upgrading from 2.2.3 to 3.0
Posted by Paulo Motta <pa...@gmail.com>.
You can migrate from the RackInferingSnitch to PropertiesFileSnitch by
populating the cassandra-topology.properties with the same rack/dc
assignments of the previous snitch (what you can't change is the
assignment, but you can change snitches if you maintain the same
assignments as before).
For example, if you were using using the RackInferingSnitch before, an
equivalent configuration on the PropertiesFileSnitch is:
IP=DC:RACK
175.56.12.105=56:12 (3rd octet is DC, 2nd is RACK on RackInferingSnitch)
175.56.13.200=56:13
175.54.35.197=54:35
120.54.24.101=54:24
There is a chance the PropertiesFileSnitch is deprecated in the near
future, so it's preferable to use the GossipingPropertyFileSnitch which is
also simpler to configure.
2015-12-02 23:30 GMT-08:00 Carlos A <na...@gmail.com>:
> Bryan, thanks for replying. I had that figured out already few days ago.
> The issue was that the snitch method was also changed on the configuration
> hence the problem.
>
> Now, if you change from rackInferingSnitch to PropertiesFileSnitch it will
> not run as the data has to be migrated. Is that correct? Or do you have the
> change the replication class on the keyspace?
>
> Putting back to rackInferingSnitch worked just fine.
>
> On Wed, Dec 2, 2015 at 6:30 PM, Bryan Cheng <br...@blockcypher.com> wrote:
>
>> Has your configuration changed?
>>
>> This is a new check-
>> https://issues.apache.org/jira/browse/CASSANDRA-10242. It seems likely
>> either your snitch changed, your properties changed, or something caused
>> Cassandra to think one of the two happened...
>>
>> What's your node layout?
>>
>> On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> I had 2 of my systems upgraded to 3.0 from the same previous version.
>>>
>>> The first cluster seem to be fine.
>>>
>>> But the second, each node starts and then fails.
>>>
>>> On the log I have the following on all of them:
>>>
>>> INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.keyspaces
>>> INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.tables
>>> INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.columns
>>> INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.triggers
>>> INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.dropped_columns
>>> INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.views
>>> INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.types
>>> INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.functions
>>> INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.aggregates
>>> INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 -
>>> Initializing system_schema.indexes
>>> ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot
>>> start node if snitch's rack differs from previous rack. Please fix the
>>> snitch or decommission and rebootstrap this node.
>>>
>>> It asks to "Please fix the snitch or decommission and rebootstrap this
>>> node"
>>>
>>> If none of the nodes can go up, how can I decommission all of them?
>>>
>>> Doesn't make sense.
>>>
>>> Any suggestions?
>>>
>>> Thanks,
>>>
>>> C.
>>>
>>
>>
>
Re: Issues on upgrading from 2.2.3 to 3.0
Posted by Carlos A <na...@gmail.com>.
Bryan, thanks for replying. I had that figured out already few days ago.
The issue was that the snitch method was also changed on the configuration
hence the problem.
Now, if you change from rackInferingSnitch to PropertiesFileSnitch it will
not run as the data has to be migrated. Is that correct? Or do you have the
change the replication class on the keyspace?
Putting back to rackInferingSnitch worked just fine.
On Wed, Dec 2, 2015 at 6:30 PM, Bryan Cheng <br...@blockcypher.com> wrote:
> Has your configuration changed?
>
> This is a new check- https://issues.apache.org/jira/browse/CASSANDRA-10242.
> It seems likely either your snitch changed, your properties changed, or
> something caused Cassandra to think one of the two happened...
>
> What's your node layout?
>
> On Fri, Nov 27, 2015 at 6:45 PM, Carlos A <na...@gmail.com> wrote:
>
>> Hello all,
>>
>> I had 2 of my systems upgraded to 3.0 from the same previous version.
>>
>> The first cluster seem to be fine.
>>
>> But the second, each node starts and then fails.
>>
>> On the log I have the following on all of them:
>>
>> INFO [main] 2015-11-27 19:40:21,168 ColumnFamilyStore.java:381 -
>> Initializing system_schema.keyspaces
>> INFO [main] 2015-11-27 19:40:21,177 ColumnFamilyStore.java:381 -
>> Initializing system_schema.tables
>> INFO [main] 2015-11-27 19:40:21,185 ColumnFamilyStore.java:381 -
>> Initializing system_schema.columns
>> INFO [main] 2015-11-27 19:40:21,192 ColumnFamilyStore.java:381 -
>> Initializing system_schema.triggers
>> INFO [main] 2015-11-27 19:40:21,198 ColumnFamilyStore.java:381 -
>> Initializing system_schema.dropped_columns
>> INFO [main] 2015-11-27 19:40:21,203 ColumnFamilyStore.java:381 -
>> Initializing system_schema.views
>> INFO [main] 2015-11-27 19:40:21,208 ColumnFamilyStore.java:381 -
>> Initializing system_schema.types
>> INFO [main] 2015-11-27 19:40:21,215 ColumnFamilyStore.java:381 -
>> Initializing system_schema.functions
>> INFO [main] 2015-11-27 19:40:21,220 ColumnFamilyStore.java:381 -
>> Initializing system_schema.aggregates
>> INFO [main] 2015-11-27 19:40:21,225 ColumnFamilyStore.java:381 -
>> Initializing system_schema.indexes
>> ERROR [main] 2015-11-27 19:40:21,831 CassandraDaemon.java:250 - Cannot
>> start node if snitch's rack differs from previous rack. Please fix the
>> snitch or decommission and rebootstrap this node.
>>
>> It asks to "Please fix the snitch or decommission and rebootstrap this
>> node"
>>
>> If none of the nodes can go up, how can I decommission all of them?
>>
>> Doesn't make sense.
>>
>> Any suggestions?
>>
>> Thanks,
>>
>> C.
>>
>
>