Cassandra CQLSH顯示錯誤的模式？

Question

我試圖從一個Cassandra集羣遷移一些數據到 另一個使用CQLSH的COPY，但我遇到了一個奇怪的問題， 列家族之一。的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'; 

然而，查詢這個表/列，當它與迴應：

[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這不在 模式中被重複使用！，我想知道如果這有什麼關係foo.quux 是一個supercolumn根據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顯示錯誤的 架構，並且該架構在某種程度上從列表2中丟失了該列2。任何幫助搞清楚如何從這個恢復將是非常歡迎 。

這可能有助於瞭解這個羣集最初（好吧，在我近兩年來在這裏的 ）運行1.2版本，但幾個月前升級到 2.0，然後升級到2.1。我們沒有注意到此升級的任何不良 影響。

另外，我有卡桑德拉的經驗非常少，所以如果你是 想「這聽起來像X，但他們一定認爲 已經是」，那麼建議也無妨＆＃X2014，因爲我最有可能還沒有 想到這一點。

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'; 
*/ 

它看起來像模式經節儉創建的，也不可能是正確 使用CQL表示。