我的一个 cassandra 集群遇到了可怕的情况。集群所在的版本是3.0.5。我正在运行一个 2 DC 设置，其中有近 30 个节点，其中 18 个在一个 DC 中，其余的在另一个 DC 中。我用我的知识尽了一切可能，但仍在寻找答案。
最近我们遇到了一些关于 GC 暂停的问题，对所有节点上的 jvm 进行了一些调整（更改了 MAX_HEAP_SIZE），并且集群已准备好滚动重启生效。
第一个节点滚动重启进展顺利，但第二个节点在关闭后没有恢复。还有下面的错误。
INFO 07:45:34 Initializing system_schema.keyspaces
INFO 07:45:34 Initializing system_schema.tables
INFO 07:45:34 Initializing system_schema.columns
INFO 07:45:34 Initializing system_schema.triggers
INFO 07:45:34 Initializing system_schema.dropped_columns
INFO 07:45:34 Initializing system_schema.views
INFO 07:45:34 Initializing system_schema.types
INFO 07:45:34 Initializing system_schema.functions
INFO 07:45:34 Initializing system_schema.aggregates
INFO 07:45:34 Initializing system_schema.indexes
Exception (java.lang.IllegalStateException) encountered during startup: One row required, 2 found
java.lang.IllegalStateException: One row required, 2 found
at org.apache.cassandra.cql3.UntypedResultSet$FromResultSet.one(UntypedResultSet.java:84)
at org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:948)
at org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:938)
at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:901)
at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:878)
at org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:866)
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:134)
at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:124)
at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:229)
at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:551)
at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:679)
在集群上运行修复后，特别是在系统键空间上，错误仍然存在。当节点最终没有出现时，我使用来自健康节点的nodetool removenode 命令将其从集群中删除。
再次在同一集群和数据中心中重新启动另一个节点，它再次没有恢复，并出现相同的错误。
我也无法从健康节点登录 cqlsh shell，并出现以下错误
Connection error: ('Unable to connect to any servers', {'<<VM hostname>>': UnicodeDecodeError('utf8', '\x7f\x00\x00\x80C\x02', 3, 4, 'invalid start byte')})
这个错误也出现在其他一些节点上
Connection error: ('Unable to connect to any servers', {'<<VM Hostname>>': ConnectionShutdown("'utf8' codec can't decode byte 0x80 in position 3: invalid start byte",)})
本质上，除了nodetool命令之外，集群没有任何功能。
当我运行 nodetool 描述集群时，我看到各个节点有 5 个不同的模式版本，并且还看到一些 9 个节点无法访问，下面是输出
./nodetool describecluster
Cluster Information:
Name: Dummy cluster
Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Schema versions:
1590ea6a-8c19-342a-8269-204c64a12176: [9 nodes here]
668d9efd-13c1-3fb3-9b89-7fc07d9ddf0b: [1 node here]
d20dc0de-dd34-3183-b459-31e3feb8f118: [3 nodes here]
3ec9610c-d241-3215-84f2-2413b8cad7d2: [7 nodes here]
59adb24e-f3cd-3e02-97f0-5b395827453f: [1 node here]
UNREACHABLE: [9 nodes unreachable]
有人可以帮助您了解问题所在以及恢复节点的方法吗？我还尝试了 cassandra-env.sh/jvm.options 中的忽略架构不匹配标志来启动节点，但这也没有帮助。
您很可能受到CASSANDRA-11900中报告的相同问题的影响，该问题最终由CASSANDRA-12144修复。您可以尝试关闭节点并迁移到更稳定的 Cassandra 3.0 版本，最新版本为 3.0.28：https://www.apache.org/dyn/closer.lua/cassandra/3.0.28/apache -cassandra-3.0.28-bin.tar.gz
因为日志中的堆栈显示迁移 system_schema 表时出现问题，如果您无法使用较新版本启动 Cassandra，那么您可以在启动之前在较新版本中尝试 sstablescrub。
由于节点数量无法访问，希望较新的版本可以帮助您解决这个问题，并且您可以从种子节点开始滚动重新启动集群以修复架构版本，否则，您需要保存“nodetool Ring”输出从在线节点，然后去掉不匹配模式版本上的节点的初始令牌值，并完成将节点引导回集群并使用“nodetool刷新”填充用户创建的表的过程，然后一旦一切完成回来了，正在修复集群。如果需要的话，可以列出这些步骤，但希望升级可以帮助您克服这个问题。
根据您发布的堆栈跟踪，您似乎遇到了从 Cassandra 2.x（2.1 或 2.2）升级到 Cassandra 3.x 后报告的已知错误。
C* 2.x 的存储格式中存在一个已知的范围逻辑删除问题，无法保证为分区仅插入一个范围逻辑删除。这会导致以新的 Cassandra 3.x 存储格式插入多行。
尽管它非常相关，但您没有提到您将集群从旧版本升级到了 Cassandra 3.0.5。这是不幸的，因为如果您升级到最新版本的 C* 3.0，这种情况本可以避免。正如 Paul 在他的回答中所述，这个问题已由 CASSANDRA-12144 在 C* 3.0.9 中修复。
Cassandra 3.0.5 已经发布了 7 年，所以它是一个非常旧的版本。该错误没有解决方法，解决方案是：
system.log$ sstableupgrade ks_name table_name
$ sstablescrub ks_name table_name
重复上述步骤，直到所有DC中的所有节点都已修复。干杯！
我几年来遇到的解决这个问题的唯一办法是，使用从备份恢复的数据设置一个新的集群，让客户端指向新集群。
sstableupgrade 和 sstablescrub 都不起作用。