Cassandra键空间不会传播到新添加的节点(在以前成功添加和删除之后)
我正在测试通过一个4节点集群进行旋转,以循环的方式添加和删除节点,以便集群的成员遵循以下重复序列Cassandra键空间不会传播到新添加的节点(在以前成功添加和删除之后),cassandra,Cassandra,我正在测试通过一个4节点集群进行旋转,以循环的方式添加和删除节点,以便集群的成员遵循以下重复序列 1 2 3 2 3 2 3 4 3 4 1 3 4 1 4 1 2 4 1 2 1 2 3 2 3 2 3 4 3 4 1 3 4 1 4 ... 通过停止cassandra、擦除/var/lib/cassandra/*、重新启动cassandra(使用相同的cassandra.yaml文件,其中将节点1和2列为种子)来执行节点添加。通过
1 2 3
2 3
2 3 4
3 4
1 3 4
1 4
1 2 4
1 2
1 2 3
2 3
2 3 4
3 4
1 3 4
1 4
...
通过停止cassandra、擦除/var/lib/cassandra/*
、重新启动cassandra(使用相同的cassandra.yaml
文件,其中将节点1和2列为种子)来执行节点添加。通过停止cassandra,然后从另一个节点发出nodetool removenode$nodeId
来执行节点删除。在所有情况下,直到上一个操作完成后才开始下一个操作
上面的节点成员序列重复了几次,直到在大约4次迭代之后,我正在执行一个“添加节点”操作,以将节点群{1,2}转换为节点群{1,2,3}。在这次迭代中,我的自定义键空间未能传播到节点3。Nodetool状态看起来很好:
$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns (effective) Host ID Rack
UN 192.168.12.206 164.88 KB 256 66.2% 7018ef8a-af08-40e9-b3d3-065f4ba6eb0d rack1
UN 192.168.12.207 60.85 KB 256 63.2% ff18b636-6287-4c70-bf23-0a1a1814b864 rack1
UN 192.168.12.205 217.19 KB 256 70.6% 2bc38fa8-42a1-457f-84d7-35b3b46e1daa rack1
但是节点3上的cqlsh
不知道我的键空间。我试图运行nodetool repair
,它似乎无限循环,同时在日志中喷出以下两个堆栈:
WARN [Thread-9781] 2014-09-16 19:34:30,081 IncomingTcpConnection.java (line 83) UnknownColumnFamilyException reading from socket; closing
org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find cfId=08768b1d-97a1-3528-8191-9acee7b08ef4
at org.apache.cassandra.db.ColumnFamilySerializer.deserializeCfId(ColumnFamilySerializer.java:178)
at org.apache.cassandra.db.ColumnFamilySerializer.deserialize(ColumnFamilySerializer.java:103)
at org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:145)
at org.apache.cassandra.service.paxos.Commit$CommitSerializer.deserialize(Commit.java:134)
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:153)
at org.apache.cassandra.net.IncomingTcpConnection.handleModernVersion(IncomingTcpConnection.java:130)
at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:74)
ERROR [Thread-9782] 2014-09-16 19:34:31,484 CassandraDaemon.java (line 199) Exception in thread Thread[Thread-9782,5,main]
java.lang.NullPointerException
at org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:247)
at org.apache.cassandra.db.RangeSliceCommandSerializer.deserialize(RangeSliceCommand.java:156)
at org.apache.cassandra.net.MessageIn.read(MessageIn.java:99)
at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:153)
at org.apache.cassandra.net.IncomingTcpConnection.handleModernVersion(IncomingTcpConnection.java:130)
at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:74)
是否知道发生了什么以及如何修复(理想情况下,是可靠的工作修复,以及一种避免首先进入此状态的方法)?如果存在架构版本不一致,您可以通过运行
nodetool descripebcluster
如果在一个节点中看到不同的版本,请执行以下版本错误的节点:
停止Cassandra服务/进程,通常通过运行:nodetool drain
sudo service cassandra stop
或kill
。
在此过程结束时,提交日志目录(/var/lib/cassandra/commitlog)应该只包含一个小文件
删除系统键空间中的Schema*和Migration*sstables(/var/lib/cassandra/data/system,如果使用默认值)
在再次启动Cassandra之后,该节点将注意到丢失的信息,并从其他节点之一拉入正确的模式。在版本1.0.X中,在应用模式之前,一次只能进行一次变异。应用时,节点可能会记录无法找到列族的消息,如下面的消息。这些消息可以忽略
ERROR [MutationStage:1] 2012-05-18 16:23:15,664 RowMutationVerbHandler.java (line 61) Error in row mutation
org.apache.cassandra.db.UnknownColumnFamilyException: Couldn't find cfId=1012
To confirm everything is on the same schema, verify that 'describe cluster;' only returns one schema version.
资料来源: