5

我曾经在 Cassandra 中收到过 OOM 异常。我的是一个运行在功率适中的服务器上的单个实例，我正在做一些负载测试，所以这并不奇怪。

但是，我随后无法使用该实例。当我列出键空间时，只显示“系统”。但是当我尝试重新创建我正在测试的密钥空间时，Hector 以可怕的“所有主机池标记为已关闭。重试负担推给客户端”作为响应。消息，并且 Cassandra 日志具有以下堆栈跟踪：

ERROR [MigrationStage:1] 2012-04-27 20:47:00,863 AbstractCassandraDaemon.java (line 134) Exception in thread Thread[MigrationStage:1,5,main]
java.lang.AssertionError
    at org.apache.cassandra.db.DefsTable.updateKeyspace(DefsTable.java:441)
    at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:339)
    at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:269)
    at org.apache.cassandra.service.MigrationManager$1.call(MigrationManager.java:214)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
ERROR [Thrift:9] 2012-04-27 20:47:00,864 CustomTThreadPoolServer.java (line 204) Error occurred during processing of message.
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.AssertionError
    at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:372)
    at org.apache.cassandra.service.MigrationManager.announce(MigrationManager.java:191)
    at org.apache.cassandra.service.MigrationManager.announceNewKeyspace(MigrationManager.java:129)
    at org.apache.cassandra.thrift.CassandraServer.system_add_keyspace(CassandraServer.java:987)
    at org.apache.cassandra.thrift.Cassandra$Processor$system_add_keyspace.getResult(Cassandra.java:3370)
    at org.apache.cassandra.thrift.Cassandra$Processor$system_add_keyspace.getResult(Cassandra.java:3358)
    at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:32)
    at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:34)
    at org.apache.cassandra.thrift.CustomTThreadPoolServer$WorkerProcess.run(CustomTThreadPoolServer.java:186)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.util.concurrent.ExecutionException: java.lang.AssertionError
    at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222)
    at java.util.concurrent.FutureTask.get(FutureTask.java:83)
    at org.apache.cassandra.utils.FBUtilities.waitOnFuture(FBUtilities.java:368)
    ... 11 more
Caused by: java.lang.AssertionError
    at org.apache.cassandra.db.DefsTable.updateKeyspace(DefsTable.java:441)
    at org.apache.cassandra.db.DefsTable.mergeKeyspaces(DefsTable.java:339)
    at org.apache.cassandra.db.DefsTable.mergeSchema(DefsTable.java:269)
    at org.apache.cassandra.service.MigrationManager$1.call(MigrationManager.java:214)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    ... 3 more

旧的键空间仍在数据目录中，所以我移动了它，但这没有帮助。似乎系统数据在某处仍有无效引用。有谁知道如何解决这一问题？

编辑：来自 CLI，“描述集群”；仅描述“系统”键空间。但是当我“使用系统”时；然后“列出 schema_keyspaces；” 显示以下内容：

Using default limit of 100
-------------------
RowKey: mango
=> (column=durable_writes, value=true, timestamp=29127788177516974)
=> (column=name, value=mango, timestamp=29127788177516974)
=> (column=strategy_class, value=org.apache.cassandra.locator.SimpleStrategy, timestamp=29127788177516974)
=> (column=strategy_options, value={"replication_factor":"1"}, timestamp=29127788177516974)

1 Row Returned.
Elapsed time: 1107 msec(s).

“芒果”是我无法再访问的键空间，但它在某种程度上仍然存在。有什么办法可以解决吗？

4

2 回答 2

2

问题几乎可以肯定是重新创建的密钥空间与提交日志或使用原始定义存储的数据不一致。关闭 Cassandra 服务器，清除 keyspace 对应的 commitlog、saved_caches 和 data 目录。这些目录的位置在 cassandra.yaml - 查找 data_file_directories、saved_caches_directory 和 commitlog_directory。

于 2012-05-02T14:48:01.390 回答
1

此问题是由于不一致造成的，您可以执行以下步骤。

1）在您的情况下，可以清除“data”、“saved_caches”和“commitlog”目录，因为您没有任何关键数据和其他键空间。

2）在您有一些关键数据并且无法删除上述目录的情况下，请执行以下操作。

  • 使用nodetool drain清空集群所有节点上的 commitlog。

  • 然后从“/data/system”目录中删除所有“LocationInfo*”文件并重新启动集群。

于 2012-05-02T15:14:53.723 回答