DSE 生产节点频繁节点宕机问题

Question

我们将生产中的 DSE 分为两个数据中心。除了 Cassandra 数据存储之外，一个数据中心正在做 Spark，一个是 SOLR。

最近我们观察到节点频繁宕机，以至于我们几乎需要花费全部时间来观察和启动 DSE 过程。

到目前为止，我们尝试删除一些旧数据，我们已经创建了一个 c# 控制台应用程序，它以 pegging 方式获取数据并将其从生产节点中删除，只是减少了节点的存储负载。

但是，我观察到一些可能会影响性能的变化，但我对此并不完全确定。

已移动机器域：我们正在更改整个组织的域。作为该过程的一部分，一些机器的域已经发生变化，而一些正在进行中。当来自同一数据中心的两台机器位于不同的域中时，当涉及到机器间通信时，它会影响内部流程吗？

频繁的数据删除进程运行：正如我提到的，我们创建了一个删除旧数据的进程，但是当我们删除数据时，它会将这些数据转换为墓碑，并且可以减慢压缩过程，这可以繁忙的 DSE 时间较长，同时可能是 scala 作业试图与客户端请求一起运行。这可能是 DSE 进程挂起。如果是这种情况，最好删除旧数据

总数据负载与节点数：截至目前，我们有近 6tb 的数据（复制因子为 3）和 15 个 DSE 节点（9 个用于 ANALYTICS，6 个用于 SOLR）。我们是否需要添加一些额外的机器来处理节点

Answer 1

回答您的一些问题：

1) 更改主机域 - 是否会影响 Cassandra。通常没有。如果您在代码/联系点中使用了主机名（如果使用的话，可能是证书），这可能会发挥作用。我不记得这是否是必需的，但我们的 yaml 文件有 IP 地址，而不是主机名，因此不会受到影响。

2) 删除数据确实会对处理和读取产生影响。其中很多可能会导致问题（压倒性的墓碑、堆恶化等）。如果必须删除，则必须删除。如果您有时间序列类型的数据，我建议您使用带有 TTL 的 TWCS 进行删除 - 因为它解决了很多问题。如果没有，您将不得不处理可能出现的墓碑和压缩问题。

3) 这个问题可能需要进一步澄清才能得到回答。每个 DC 上是否有 6TB 的数据（即分析 DC 上的数据为 6TB，SOLR DC 上的数据为 6TB），包括所有副本在内的总计 6TB（例如，用于分析的 3TB 和用于 SOLR 的 3TB），或在任何副本之前有 6TB 的数据计数（即包括副本时总共 18TB）？

至于您关于注意到节点出现故障的初始陈述。你确定他们为什么会倒下吗？ cassandra 日志文件揭示了什么？在我们的环境中，如果一个节点出现故障，通常有以下几个原因：

1) GC 问题 - 如果 GC 花费的时间过长，这可能会导致大问题并最终取出节点。在您的 system.log 中查找“GCInspector”以了解 GC 需要多长时间。

2) 堆内存问题 - DSE 的每个版本似乎都消耗更多内存，而在 DSE 6.X 中，您需要注意发生的一些 yaml 更改（一些配置更改现在默认为 OFF- HEAP，这将导致比以前的版本更多的内存消耗）。在系统日志文件中，尤其是在 DSE 6.X（在我们的案例中为 6.7）中，我看到了很多“Out Of (Heap) Memory”消息，这些消息导致节点被占用。如果您使用的是 6.7.3 并使用节点同步，则存在一个已知的内存泄漏错误（我们遇到过）会导致此问题。升级/修补到 6.7.4。

3) O/S 内存问题 - 我们有一些没有很多内存的环境 - 20GB，并且 O/S 启动 OOM Killer 以释放内存，杀死 DSE 和/或 datastax 中的一个或两个代理 (OpsCenter)。

这些是我多年来看到的主要原因，但系统日志文件中可能会显示其他原因。

-吉姆