Question

我一直在使用Cassandra 2.1.7并且由于某种原因我升级到3.0.12后来意识到一些依赖的应用程序将无法与3.0.12一起工作并且我降级并使用C * 2.1.7因为我是使用之前。但是现在我无法在C *中看到Keyspaces。（仅供参考：两个C * yaml文件中的数据目录相同）

我是否需要进行任何更改？

感谢您的帮助。

Answer 1

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

Answer 2

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

以下是我为保留数据所做的工作：由于3.0对数据库名称的命名约定完全不同，因此我们需要仔细区分数据库与旧数据库（较旧与较新）。

对于2.X Cassandra 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文件不是实际文件，因为这个文件的大小非常小。 / p>

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

所以我试图从快照中找到系统下的最旧文件（密钥空间目录，即/ data / system /），并将其替换为上述文件。我在系统键空间下重复了“schema_keyspaces”表。

现在我再次重启cassandra守护进程，幸运的是，在运行“ DESC KEYSPACES ”后，我可以获得键空间列表但是当我为我的密钥空间执行“ DESC TABLES”时，我没有看到表的列表，因为它没有加载，因为sstable_activity找不到文件。

现在，我继续为“system”键空间下的所有其他表重复相同的过程。如下：

schema_keyspaces
schema_columnfamilies
local
schema_columns
schema_triggers
schema_usertypes

重新启动Cassandra后，我能够检索我期望的应用程序日期。

在我从3.0降级到2.1.7之后，无法看到C * 2.1.7中的所有键空间

2 个答案: