Cassandra 1.1.1 - Update Keyspace Not Working

(8 posts) (2 voices)

• Started 11 months ago by adang
• Latest reply from xedin
• This topic is not resolved

Tags:

No tags yet.

1. 

   adang
   Member

   I'm currently running this command
   
[default@nmsConfig] update keyspace nmsConfig with placement_strategy='org.apache.cassandra.locator.SimpleStrategy' and strategy_options={replication_factor:3};

   and my when I do a describe on the keyspace, nothing has updated.
   
Keyspace: nmsConfig:
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
Durable Writes: true
Options: [SNCC3:3, SNCC1:3]

   As you can see, everything seems to remain the same after the command. I've tried doing it a few different times under different circumstances, but the keyspace doesn't update.

   Posted 11 months ago #
2. 

   xedin
   Member

   What does update keyspace command return to you? Have you tried to look at system.log to figure out what is happing in Cassandra after you run that command?

   Posted 11 months ago #
3. 

   adang
   Member

   
315db8fc-6440-3e19-ab10-7b4f5c13b514
Waiting for schema agreement...
... schemas agree across the cluster


   This is what I get from running the update command.

   I'm not exactly sure what I should be looking for in the system.log file. I don't see any exceptions that could've have been caused by the command. Should I be concerned with the StorageService.java or GCInspector.java?

   Posted 11 months ago #
4. 

   xedin
   Member

   Are you doing frequent schema updates? I have tested on my server right now and 'update keyspace' worked just fine chaning NTS to SS. can you open a CLI and do 'use system;', 'list schema_keyspaces;' and post the output here?

   Posted 11 months ago #
5. 

   adang
   Member

   No. We're not doing schema updates. We're just trying to setup data replication across Cassandra nodes from a seed node that does contain the data.

   
[default@nmsConfig] use system;
Authenticated to keyspace: system
[default@system] list schema_keyspaces
... ;
Using default limit of 100
Using default column limit of 100
-------------------
RowKey: nmsConfig
=> (column=durable_writes, value=true, timestamp=1611762403080531)
=> (column=name, value=nmsConfig, timestamp=1611762403080531)
=> (column=strategy_class, value=org.apache.cassandra.locator.NetworkTopologyStrategy, timestamp=1611762403080531)
=> (column=strategy_options, value={"SNCC3":"3","SNCC1":"3"}, timestamp=1611762403080531)
-------------------
RowKey: nmsStatus
=> (column=durable_writes, value=true, timestamp=1611781564065266)
=> (column=name, value=nmsStatus, timestamp=1611781564065266)
=> (column=strategy_class, value=org.apache.cassandra.locator.NetworkTopologyStrategy, timestamp=1611781564065266)
=> (column=strategy_options, value={"SNCC3":"3","SNCC1":"3"}, timestamp=1611781564065266)

   2 Rows Returned.
Elapsed time: 180 msec(s).


   Posted 11 months ago #
6. 

   xedin
   Member

   Interesting, this output means that you 'update keyspace' command wasn't actually applied or it was applied but the timestamp of the migration (time when you ran it) was somehow less than time of NTS update do you have your clocks synchronized? Also can you try creating new keyspace with default settings (just 'create keyspace ks' in CLI) and try to update it to use SS ?

   Posted 11 months ago #
7. 

   adang
   Member

   The update command did work when I created a new keyspace. I'm not sure what you mean by synchronizing the clocks. Which clocks are you referring to?

   Posted 11 months ago #
8. 

   xedin
   Member

   I mean OS clocks on your nodes. If the 'update keyspace' command worked on the new keyspace that means that previous commands didn't get applied or clocks were not synchronized properly so the older data merged on to of new - if that is possible you can try to re-create your 'nmsConfig' keyspace and run few 'update keyspace' commands on it to see if everything works after timestamps in system.schema_keyspaces were updated...

   Posted 11 months ago #

RSS feed for this topic