2017-10-05 35 views
1

我一直在使用Cassandra 2.1.7,出于某种原因,我升级到3.0.12,后来意识到一些依赖应用程序赢了没有3.0.12的工作,我降级和使用C * 2.1.7,因为我以前使用。但是现在我无法在C *中看到密钥空间。 (仅供参考:两个C * yaml文件中的数据目录相同)在我从3.0降级到2.1.7后,无法看到C * 2.1.7中的所有密钥空间

我必须做出任何更改吗?

感谢您的帮助。

+0

无法看到任何密钥区是什么意思?它也是系统密钥空间吗?如果运行DESC KEYSPACES,会发生什么情况? –

+0

是的西蒙,我只能看到系统和system_traces,我没有看到我创建的其他密钥空间。 – Avis

回答

0

如果您没有采取备份,那么没有什么可担心的,因为C * 3.0在升级后不会删除旧的dbs,它只是更新sstable相关的CFS并添加了一些更多的CFS以实现兼容性。

这里是我做了什么,保留数据: 由于3.0对数据库的名称完全不同的命名规则,我们需要从两个仔细辨别分贝(旧VS更新)。

对于2.X卡桑德拉dbnames已经为每个KS以下约定:

keyspace-ColumnFamilyName-ka-ID-Data.db 
keyspace-ColumnFamilyName-ka-ID-Digest.sha1 
keyspace-ColumnFamilyName-ka-ID-Filter.db 
keyspace-ColumnFamilyName-ka-ID-Index.db 
keyspace-ColumnFamilyName-ka-ID-Statistics.db 
keyspace-ColumnFamilyName-ka-ID-Summary.db 
keyspace-ColumnFamilyName-ka-ID-TOC.txt 

keyspace: keyspace name 
ColumnFimilyname : Name of the CF under keyspace 
ka: C* Internal(Haven't explored much on this) 
ID: It is incremental value I see different sets of these having different id.(looks like it is an increasing factor when it takes snapshot, not sure though) 
And the last parameter is db name 

所以,当我开始与我2.1.7通过每一个日志语句在C *守护的阅读和发现,系统密钥空间下的sstable_actiivity文件不是实际的文件,因为该文件的大小非常小。

/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/system-sstable_activity-ka-145 

所以我试图找到从快照系统下最老的文件(密钥空间目录即/数据/系统/)和替换上述文件。 和我在系统密钥空间下的“schema_keyspaces”表中重复的一样。

现在我再次重新启动卡桑德拉守护程序,幸运的是,我以后运行“DESC KEYSPACES” 但我没有看到表列表当我执行“DESC TABLES”我的密钥空间,因为我可以得到keyspaces名单它没有加载,因为文件没有被sstable_activity找到。

现在我一直对“system”keyspace下的所有其他表格重复相同的过程。如下所示:

schema_keyspaces 
schema_columnfamilies 
local 
schema_columns 
schema_triggers 
schema_usertypes 

重新启动Cassandra后,我能够检索到我的应用程序的预期日期。

1

当您从2.x升级到3.x时,您必须在nodetool中运行upgradesstables命令。我认为这就是你所做的。现在,当您降级到2.x时,Cassandra无法阅读更新的SSTable格式。不幸的是,没有downgradesstables命令,所以你唯一的选择就是从第一次运行2.x的位置恢复备份。

+0

其实我没有执行任何nodetool活动,我只是升级,并能够使用cqlsh查询表,并认为我的应用程序将能够读取相同的,但由于火花C *驱动程序的问题,我试图降级到2.x – Avis

+0

我'发布我的答案,因为这对我有效,请纠正相同的西蒙,如果你看到有些事情我做错了。 – Avis

相关问题