在cassandra *中设置密钥空间，而不需要*复制因子

时间：2012-07-23 11:26:22

标签： cassandra

我们从cassandra集群（1.0.10）中获得了奇怪的行为。

我们正在运行一个3节点集群。

如果我创建一个没有设置复制因子的密钥空间，那么在尝试输入数据时会出错：

[default@unknown] create keyspace foo;
ae639ba0-d4b8-11e1-0000-424d3d43a8df
Waiting for schema agreement...
Warning: unreachable nodes 10.227.65.172, 10.51.62.63... schemas agree across the cluster
[default@unknown] use foo;
Authenticated to keyspace: foo
[default@foo] create column family User with comparator = UTF8Type;
b4608180-d4b8-11e1-0000-424d3d43a8df
Waiting for schema agreement...
Warning: unreachable nodes 10.227.65.172, 10.51.62.63... schemas agree across the cluster
[default@foo] update column family User with
...             column_metadata =
...             [
...             {column_name: first, validation_class: UTF8Type},
...             {column_name: last, validation_class: UTF8Type},
...             {column_name: age, validation_class: UTF8Type, index_type: KEYS}
...             ];
b70562c0-d4b8-11e1-0000-424d3d43a8df
Waiting for schema agreement...
Warning: unreachable nodes 10.227.65.172, 10.51.62.63... schemas agree across the cluster
[default@foo] set User['jsmith']['first'] = 'John';
null
UnavailableException()
        at org.apache.cassandra.thrift.Cassandra$insert_result.read(Cassandra.java:15206)
        at org.apache.cassandra.thrift.Cassandra$Client.recv_insert(Cassandra.java:858)
        at org.apache.cassandra.thrift.Cassandra$Client.insert(Cassandra.java:830)
        at org.apache.cassandra.cli.CliClient.executeSet(CliClient.java:901)
        at org.apache.cassandra.cli.CliClient.executeCLIStatement(CliClient.java:218)
        at org.apache.cassandra.cli.CliMain.processStatementInteractive(CliMain.java:220)
        at org.apache.cassandra.cli.CliMain.main(CliMain.java:348)

（无法访问节点的问题不应该是here）

所述的问题

但是，如果我创建了键空间并指定了复制因子（1,2或3），那么它可以正常工作。

如果在创建群集时没有指定复制因子存在问题，那么不应该在创建时抛出异常吗？如果不在多节点群集上指定复制因子，那么预期的行为是什么？

1 个答案:

答案 0 :(得分：3)

从cassandra-cli内部创建密钥空间时的默认复制策略是NetworkTopologyStrategy（NTS），它实际上没有单个replication_factor的概念。 NTS的副本基于每个数据中心进行配置。使用NTS时的默认复制选项是“{datacenter1:1}”，这意味着应将一个副本放在“datacenter1”副本组中。如果您没有配置特定的snitch，那么很可能所有节点都被分配到“datacenter1”。

我对如何将复制因子设置为1,2或3感到困惑，因为cassandra-cli不允许您指定replication_factor而不指定placement_strategy {{1}如果你这样做，我认为你会更加意识到这种差异。

无论如何，由于您在默认情况下的有效复制因子是1，我希望您的问题确实是警告消息中的向下节点。它们是真正的僵尸节点，正如你引用的邮件中所讨论的那样，还是它们仍然存在于环中并且无法访问的真实节点？ SimpleStrategy的输出应该有助于诊断为什么Cassandra不认为它可以成功存储您的记录。

最后，我应该指出，使用nodetool ring工具比使用cqlsh更容易找到 lot 这类工作。在这种情况下，它至少会迫使您提供明确的复制策略和策略选项。

相关问题
最新问题