Cassandra - 每次在CQLSH中发出的命令都会抛出错误

Question

Cassandra让我头疼。昨天一切都运行正常，然后我删除了一个表，运行了一个CQLSSTableWriter，它以某种方式多次抛出关于我的Lucene index（不在类路径上或类似的问题）的错误，现在，我在cqlsh中发出的每个命令都会抛出错误。

CREATE KEYSPACE IF NOT EXISTS mydata WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'};

需要一些时间，然后抛出异常：

Warning: schema version mismatch detected, which might be caused by DOWN nodes; 
if this is not the case, check the schema versions of your nodes in system.local and system.peers. 
OperationTimedOut: errors={}, last_host=XXX.XXX.XXX.20

之后我将创建一个新的表，但它也会抛出相同的错误。

cqlsh:mydata> create table test (id text PRIMARY KEY, id2 text);
Warning: schema version mismatch detected, which might be caused by DOWN nodes; if this is not the case, check the schema versions of your nodes in system.local and system.peers.
OperationTimedOut: errors={}, last_host=XXX.XXX.XXX.20

last_host 总是显示我运行 cqlsh 的主机的 IP。我也尝试了在不同节点上使用相同的命令。

但是 keyspace 和 table 仍在创建中！错误消息指出模式版本不匹配，因此我确保运行了：

nodetool describecluster

执行命令的输出显示，我的所有节点都在同一个模式下，没有模式不匹配的情况。我之前也执行了nodetool resetlocalschema，但没有任何运气。

当我尝试插入一些数据到新创建的表格中时，会出现以下错误。请注意，插入语句不会返回错误。

cqlsh:mydata> insert into test(id, id2) values('test1', 'test2');
cqlsh:mydata> select * from mydata.test ;
Traceback (most recent call last):
  File "/usr/bin/cqlsh.py", line 1314, in perform_simple_statement
    result = future.result()
  File "/usr/share/cassandra/lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", line 3122, in result
    raise self._final_exception
Unavailable: code=1000 [Unavailable exception] message="Cannot achieve consistency level ONE" info={'required_replicas': 1, 'alive_replicas': 0, 'consistency': 'ONE'}

请注意，我有一个数据中心和五个节点。 我未来不打算使用多个数据中心。[cqlsh 5.0.1 | Cassandra 3.0.8 | CQL规范3.4.0 | 本地协议v4]

我已经多次重启了Cassandra。 nodetool状态显示所有节点都正在运行。有人知道发生了什么吗？

- j9dy

Answer 1

我通过以下方法解决了这个问题：

1. 删除keyspace中的所有表

2. 运行alter keyspace mydata WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': '1'};而不是SimpleStrategy

3. 重新启动所有节点上的cassandra服务

4. 重新创建所有表

5. 运行nodetool repair

现在，我可以再次插入数据和查询数据。但说实话，我仍然不太确定导致这一切的原因。

- j9dy

---

通常情况下，可以通过重启受影响的节点（可以通过运行命令 nodetool describecluster 查看）来解决模式不一致的问题。很高兴你已经解决了这个问题。 - Aaron

@Aaron 这正是让我头疼的部分。nodetool describecluster 的输出一直是这样的：`9ae01f7c-c138-31ee-a9d1-d11527c2471b: [xxx.xxx.xxx.24, xxx.xxx.xxx.28, xxx.xxx.xxx.30, xxx.xxx.xxx.32, xxx.xxx.xxx.20] UNREACHABLE: [127.0.0.1]`。如上面的问题所述，我原本以为这意味着没有模式不一致。 - j9dy

“UNREACHABLE: [127.0.0.1]”让我担心。如果这不是您的集群中的有效节点，我建议在其上执行“nodetool removenode”操作...然后在所有其他节点上从system.peers中删除它。否则，该127.0.0.1将被困在旧模式中，并继续报告不一致。 - Aaron

@Aaron，我已经成功删除了节点127.0.0.1。现在，nodetool describecluster显示出有效的输出，不包括127.0.0.1节点。感谢您的帮助。 - j9dy