0

After playing with Cassandra (many DROP KEYSPACE, CREATE KEYSPACE, ALTER TABLE, CREATE TABLE operations), for the second time I've ended up with following strange situation:

Describe x.logs: Describe x.logs

System.schema_columns: System.schema_columns

Alter table: Alter table

Nodetool repair doesn't fix it. After dropping the keyspace everything goes back to normal.

My configuration:

  • 1 Cassandra node cluster
  • cqlsh 5.0.1
  • Cassandra 2.2.0
  • CQL spec 3.3.0 | Native protocol v4

Questions:

  • What happened?
  • Why that happened? Is it dangerous?
  • How can I fix it?
piotrwest
  • 2,098
  • 23
  • 35

1 Answers1

0

It seems like the driver metadata model (used by cqlsh) is out of sync. This is not expected since the driver refreshes schema synchronously with DDL statements.

If you stop and restart cqlsh it will DESC what's there.

Adam Holmberg
  • 7,245
  • 3
  • 30
  • 53
  • Cqlsh is a normal utility, right? I should just connect again? If that's the case, it sees "old" schema even after putty restart. – piotrwest Aug 25 '15 at 05:57
  • By "old", do you mean the first DESC output you show above? In that case I'm even more surprised. It sounds like schema metadata might be in some unexpected state. Reproduction steps would be key here. – Adam Holmberg Aug 25 '15 at 14:07
  • Yes. So am I... Do you know if it is dangerous? Maybe someday I'll figure out the reproduction steps. – piotrwest Aug 25 '15 at 14:54
  • Probably not dangerous, but definitely confusing. Could you tell me what columns are displayed if you `SELECT * FROM x.user;`? – Adam Holmberg Aug 25 '15 at 16:46
  • id, time, foruser, li_ip, li_l, li_n, r_e, r_ip, r_l, r_n, type - so the full set of columns. Do you know maybe what data cqlsh describe command uses? – piotrwest Aug 26 '15 at 07:11
  • It uses that exact data to construct a model of the table. I'm not sure how the model could be inconsistent with the table in a single-node cluster. – Adam Holmberg Sep 03 '15 at 13:20