Apache spark DSE生产节点频繁节点故障问题

我们将生产中的DSE分为两个数据中心。除卡桑德拉数据存储外，还有一个数据中心是spark，另一个是SOLR

最近，我们观察到节点频繁下降，几乎需要花费全部时间来观察和启动DSE进程

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

然而，我观察到一些可能影响性能的变化，但我不能完全肯定这一点

移动了机器域：我们正在整个组织内更改域。作为过程的一部分，一些机器的域已经改变，一些正在进行中。当来自同一数据中心的两台机器位于不同的域时，它是否会影响机器间通信的内部进程

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

---

总数据负载与节点数之比：到目前为止，我们拥有近6tb的数据（复制系数为3）和15个DSE节点（9个用于分析，6个用于SOLR）。我们是否需要添加一些额外的机器来处理节点来回答您的一些问题：

1） 更改主机域-是否会影响Cassandra。通常不会。如果您在代码/联系人中使用了主机名（如果使用了证书，则可能是证书），则可能会出现这种情况。我不记得这是否是一个要求，但我们的yaml文件有IP地址，而不是主机名，所以这些不会受到影响

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

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

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

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

2） 堆内存问题-DSE的每个版本似乎都会消耗更多的内存，对于DSE 6.X，您需要注意发生的一些yaml更改（一些配置更改现在默认为非堆，这将导致比以前版本更多的内存消耗）。在系统日志文件中，特别是在DSE 6.X（在我们的例子6.7中）中，我看到了许多“内存（堆）不足”消息，这些消息已经删除了节点。如果您使用的是6.7.3，并且您使用的是节点同步，那么有一个已知的内存泄漏错误（我们遇到的）将导致此问题。升级/修补到6.7.4

3） O/S内存问题—我们有些环境没有太多内存—20GB，O/S启动OOM Killer释放内存，杀死DSE和/或datastax代理（OpsCenter）

这些是我多年来看到的主要原因，但可能还有其他原因会在系统日志文件中披露

-Jim

你也可以在上询问-有来自税务支持等部门的人。