Cassandra CQLSH 显示错误的架构？

Question

我正在尝试将一些数据从一个 Cassandra 集群迁移到另一个使用 CQLSH 的 COPY，但我运行遇到了 st运行ge 问题列族之一。 foo.quux 的架构，如 cqslsh，看起来像这样：

CREATE TABLE foo.quux (
    key blob,
    column1 blob,
    value blob,
    PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE
    AND CLUSTERING ORDER BY (column1 ASC)
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.SnappyCompressor'}
    AND dclocal_read_repair_chance = 0.0
    AND default_time_to_live = 0
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.1
    AND speculative_retry = '99.0PERCENTILE';

但是，当查询此 table/column 时，它会响应：

[cqlsh 5.0.1 | Cassandra 2.1.15 | CQL spec 3.2.1 | Native protocol v3]
Use HELP for help.
cqlsh> select * from foo.quux limit 3;

 key                                                                  | column1                  | column2 | value
----------------------------------------------------------------------+--------------------------+---------+------------------------
 0x443635316337656439326336373436363661623363373833616131626364623762 | 0x31e2988335373035393739 |    0x61 |             0x54727565
 0x443635316337656439326336373436363661623363373833616131626364623762 | 0x31e2988335373035393739 |    0x63 | 0x31343739393832343931
 0x443635316337656439326336373436363661623363373833616131626364623762 | 0x31e2988335373035393739 |  0x6c72 |             0x4e6f6e65

(3 rows)

请注意，此输出有一个 column2 未在 schema! 我想知道这是否与 foo.quux 有关根据 cassandra-cli（这也不是据我所知，在 QCLSH 模式输出中表示）：

create column family quux
  with column_type = 'Super'
  and comparator = 'BytesType'
  and subcomparator = 'BytesType'
  and default_validation_class = 'BytesType'
  and key_validation_class = 'BytesType'
  and read_repair_chance = 0.1
  and dclocal_read_repair_chance = 0.0
  and gc_grace = 86400
  and min_compaction_threshold = 4
  and max_compaction_threshold = 32
  and compaction_strategy = 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'
  and caching = 'KEYS_ONLY'
  and cells_per_row_to_cache = '0'
  and default_time_to_live = 0
  and speculative_retry = '99.0PERCENTILE'
  and compression_options = {'sstable_compression' : 'org.apache.cassandra.io.compress.SnappyCompressor'};

所以，我怀疑问题是cqslsh显示错误 schema，出于某种原因，column2 不知何故从模式。弄清楚如何从中恢复的任何帮助都是非常欢迎。

了解这个集群最初（好吧，在我来这里已经将近 2 年了）运行 1.2 版，但已升级到 2.0 和几个月前的 2.1。我们没有发现任何不好的此升级的效果。

另外，我对 Cassandra 的经验很少，所以如果你认为“这听起来像 X，但他们一定已经想到了已经”然后建议它——因为我很可能 还没有 想到了。

Answer 1

谜底解开了？我尝试用不同的方式连接到集群 cqlsh 程序（直接来自我的 Mac），但集群现在报告不支持 3.3.1 的 CQLVersion，我不得不使用 3.2.1 反而。现在我从 DESCRIBE:

得到不同的结果

cqlsh --cqlversion 3.2.1 52.206.209.178 -e 'DESCRIBE foo.quux;'

/*
Warning: Table foo.quux omitted because it has constructs not compatible with CQL (was created via legacy API).

Approximate structure, for reference:
(this should not be used to reproduce this schema)

CREATE TABLE foo.quux (
    key blob,
    column1 blob,
    value blob,
    column2 blob,
    PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE
    AND CLUSTERING ORDER BY (column1 ASC)
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.0
    AND default_time_to_live = 0
    AND gc_grace_seconds = 86400
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = 'NONE';
*/

看起来模式是通过 Thrift 创建的，不能使用 CQL 正确表示。

Cassandra CQLSH 显示错误的架构？

Cassandra CQLSH shows the wrong schema?

cqlsh

cassandra-2.1