Cassandra节点JVM在节点修复期间挂起

Question

我在AWS上有一个9个节点的集群。最近，一些节点已关闭，我想在重新启动它们后修复群集。但是我发现修复操作导致大量的内存刷新，然后JVM GC失败。因此，该节点挂起。

我正在使用cassandra 3.1.0。

java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b32)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b32, mixed mode)

节点硬件为32GB内存和4核CPU。堆是16GB。对于每个节点，大约有200 GB的sstable。

JVM挂起非常快。修复过程开始后，一切正常。我检查了内存，CPU和IO。找不到压力。经过一段随机时间（对于一个特定的表，可能是20分钟），memtableflushwriter挂起的任务迅速增加，然后GC失败。 JVM挂起并创建了heapdump。发生问题时，CPU使用率很低，我无法在AWS EBS磁盘指标上找到I / O延迟。

我检查了堆转储文件。表修复有几个大的memtables对象。内存对象的大小约为400-700MB。我很困惑为什么尚未刷新内存表。

起初，我怀疑内存不足的刷新写入器是瓶颈。所以我将其增加到4个线程。而且我将节点的内存增加了一倍。但这是行不通的。在修复期间，挂起的任务迅速增加，然后节点再次挂起。我也减小了修复令牌的范围，只有一个vnode，但仍然失败。

我们可以看到一些这样的日志

WARN [STREAM-IN-/10.0.113.12:7000] 2020-04-02 05:05:57,150 BigTableWriter.java:211 - Writing large partition ....

写入稳定表具有300-500 MB。一些大的达到2+ GB。因此，我怀疑分区大小会导致此问题。在几个表中，分区键设计得不好。在过去的两年中，分区中的数据非常大。

我的问题如下。

1. 在Cassandra修复中，流数据是否已写入memtable，然后刷新到磁盘？我遍历了代码，但是没有找到它。另一方面，我在堆转储中看到几个正在修复的内存表。
2. 从其他节点接收的数据将不会刷新到磁盘，直到加载分区中的所有数据？
3. 还有其他可能性吗？

非常感谢

Answer 1

Cassandra中的修复不使用内存表-它使用与节点引导等相同的流传输机制。但是，如果您有大分区并且它们已损坏，则Cassandra将需要发送它们，然后接收方需要建造辅助结构等。您可以在following blog post中找到有关维修可能出现的问题的更多信息。

可能的解决方案之一是使用范围修复，因此您只能检查令牌环的特定部分。但是手动执行此操作很繁琐，因此最好使用Cassandra Reaper之类的工具来自动执行此过程。