我在我的一个cassandra集群上遇到了一个可怕的情况。集群的版本是3.0.5。我正在运行一个有近30个节点的2个DC设置，其中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命令将其从集群中删除。
在同一群集和数据中心中，另一个节点再次被占用以重新启动，它再次没有恢复，并出现相同的错误。
我也无法从正常运行的节点登录到cqlshshell，并显示以下错误
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 describe cluster时，我看到了不同节点的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]有人能帮助我们了解问题所在吗？还有一种方法可以恢复节点吗？我还尝试了www.example.com中的ignore schema mismatch标志cassandra-env.sh/jvm.options来恢复节点，但也没有帮助。
2条答案
按热度按时间nr9pn0ug1#
您很可能会受到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 refresh'填充用户创建的表的过程，然后一旦一切都恢复，修复集群。如果需要的话，这些步骤可以安排好，但希望升级可以让你度过这一关。
sycxhyv72#
根据您发布的堆栈跟踪，您似乎遇到了一个已知的错误，该错误是在从Cassandra 2.x（2.1或2.2）升级到Cassandra 3.x后报告的。
在C* 2.x的存储格式中存在一个已知的范围逻辑删除问题，它不能保证一个分区只插入一个范围逻辑删除。这会导致在新的Cassandra 3.x存储格式中插入多行。
虽然这是高度相关的，但你没有提到你将集群从旧版本升级到了Cassandra 3.0.5。这是很不幸的，因为如果你升级到最新版本的C* 3.0，这是可以避免的。正如Paul在他的回答中所说，这个问题在C* 3.0.9中由CASSANDRA-12144修复。
Cassandra 3.0.5是7年前发布的，因此是一个非常旧的版本。对于此错误没有解决方法，解决方法是：
1.从种子节点开始，将二进制文件升级到最新的C* 3.0版本。
1.对于每个受影响的表（检查
system.log），使用以下内容升级SSTables：1.对于每个受影响的表，使用以下命令清除重复的行：
1.在节点上启动Cassandra。
1.在下一个节点上重复上述步骤。
重复以上步骤，直到所有DC中的所有节点都已修复。干杯！