cassandra - 在现有 key 空间 : Column family ID mismatch 上使用 cqlsh 创建新表

Question

休斯顿，我们有一个问题。

试图用 cqlsh 创建一个新表在现有的 Cassandra (v2.1.3) 键空间上会导致:

ServerError: 
<ErrorMessage code=0000 [Server error] message="java.lang.RuntimeException:
java.util.concurrent.ExecutionException: 
    java.lang.RuntimeException:      
        org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found e8c03790-c952-11e4-a753-5981ea73cd7c; expected e8b14370-c952-11e4-a844-8f10bfb9c386)">

第一次创建尝试后，再次尝试将导致:

已经存在:表 'ks.metrics' 已经存在

但是检索键空间的现有表列表 desc tables;不会报告新表。

该问题似乎与 Cassandra-8387 有关除了只有一个客户端尝试创建表: cqlsh
我们确实有一堆 Spark 作业，它们将在启动时创建键空间和表，并可能并行执行此操作。这会导致 key 空间损坏吗？

创建一个新的键空间并向其添加表按预期工作。

有任何想法吗？

更新

找到了一个解决方法:对键空间进行修复，表将出现 ( desc tables ) 并且也能正常工作。

Answer 1

简答: They have a race condition ，他们认为他们在 中解决了这个问题1.1.8 ...

长答案:

我一直在我的一个集群上收到该错误。我有测试机器的硬盘驱动器非常慢，当我在两台不同的计算机上有 4 个节点时，创建一两个表就足以导致错误。

下面是我的 Cassandra 3.7 安装中堆栈跟踪的副本。尽管您的版本是 2.1.3，但我会惊讶地发现这部分代码发生了如此大的变化。

正如我们所见，异常发生在 validateCompatibility()功能。这要求 MetaData 的新旧版本具有以下相等性:

ksName(键空间名称)

cfName(列族名称)

cfId(列族 UUID)

标志(isSuper、isCounter、isDense、isCompound)

比较器(键排序比较器)

如果这些值中的任何一个在旧元数据和新元数据之间不匹配，则该过程会引发异常。在我们的例子中， cfId值(value)观不同。

向上堆栈，我们有 apply()其中调用 validateCompatibility()立即地。

接下来我们有 updateTable() .同样，它调用 apply()几乎立即。首先它调用 getCFMetaData()检索要与新数据进行比较的当前列族数据(“旧”)。

接下来我们看到 updateKeyspace() .该函数计算 diff知道发生了什么变化。然后它将其保存在每种类型的数据中。表是类型后的第二个...

在此之前，他们有 mergeSchema()它计算在 Keyspace 级别发生了什么变化。然后它删除被删除的键空间并为更新的键空间(以及新的键空间)生成新的键空间。最后，他们循环调用 updateKeyspace() 的新键空间。对于他们中的每一个。

接下来在堆栈中我们看到一个有趣的函数: mergeSchemaAndAnnounceVersion() .一旦 key 空间在内存和磁盘上更新，这个将更新版本。架构的版本包括 cfID这是不兼容的，因此会产生异常。 Announce部分是向其他节点发送关于该节点现在知道某个模式的新版本的事实的八卦消息。

接下来我们看到一个叫做 MigrationTask 的东西.这是用于在 Cassandra 节点之间迁移更改的消息。消息负载是一组突变(由 mergeSchema() 函数处理的那些。)

堆栈的其余部分仅显示 run()函数是用于处理消息的各种类型的函数。

就我而言，对我来说，问题会在稍后解决，一切都很好。我对架构最终同步无事可做。正如预期的那样。但是，它阻止我一次性创建所有表。因此，我认为迁移消息未按预期顺序到达。必须有一个超时，通过重新发送事件来处理并产生混淆。

因此，让我们首先查看发送消息的代码，您会在 MigrationManager 中看到该代码。这里我们有一个 MIGRATION_DELAY_IN_MS旧问题链接中的参数， Schema push/pull race ，这是为了避免竞争条件。嗯……就这样吧。所以他们意识到可能存在竞争条件并试图避免它，他们在那里增加了一点延迟。该修复的一部分包括版本检查。如果版本已经相等，则完全避免更新(即忽略该八卦)。

if (Schema.instance.getVersion().equals(currentVersion))
{
    logger.debug("not submitting migration task for {} because our versions match", endpoint);
    return;
}

我们所说的延迟是一分钟:

public static final int MIGRATION_DELAY_IN_MS = 60000;

有人会认为整整一分钟就足够了，但不知何故，我仍然总是遇到错误。

事实是，他们的代码并不期望一个接一个地发生多次更改，包括像我这样的大延迟。因此，如果我要创建一张表，然后再做其他事情，那就没问题了。另一方面，当我想在那些慢速机器上连续创建 20 个表时，来自先前架构更改的八卦消息迟到(即在新的 CREATE TABLE 命令到达该节点之后。)那是我收到错误的时候.我想，最糟糕的部分是它是一个虚假错误(即它告诉我八卦是后来的，而不是我的架构无效并且八卦消息中的架构是旧的。)

org.apache.cassandra.exceptions.ConfigurationException: Column family ID mismatch (found 122a2d20-9e13-11e6-b830-55bace508971; expected 1213bef0-9e
    at org.apache.cassandra.config.CFMetaData.validateCompatibility(CFMetaData.java:790) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.config.CFMetaData.apply(CFMetaData.java:750) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.config.Schema.updateTable(Schema.java:661) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.updateKeyspace(SchemaKeyspace.java:1350) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchema(SchemaKeyspace.java:1306) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.schema.SchemaKeyspace.mergeSchemaAndAnnounceVersion(SchemaKeyspace.java:1256) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.service.MigrationTask$1.response(MigrationTask.java:92) ~[apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:53) [apache-cassandra-3.9.jar:3.9]
    at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64) [apache-cassandra-3.9.jar:3.9]
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_111]
    at java.util.concurrent.FutureTask.run(FutureTask.java:266) [na:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_111]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_111]
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]