我们生产的dse分为两个数据中心。一个数据中心是spark，另一个是solr，除了cassandra数据存储。
最近，我们观察到节点频繁下降，以至于我们几乎需要花费全部时间来观察和启动dse过程。
到目前为止，我们尝试删除一些旧数据，我们已经创建了一个c#console应用程序，该应用程序以固定方式获取数据并将其从生产节点中删除，只是减少了节点的存储负载。
然而，我观察到了一些可能影响性能的变化，但我不能完全肯定这一点。
移动的机器域：我们正在改变整个组织的域。作为这个过程的一部分，一些机器的域已经改变，一些正在进行中。当来自同一数据中心的两台机器在不同的域中进行机器间通信时，它会影响内部进程吗？
频繁的数据删除过程运行：正如我提到的，我们创建了一个删除旧数据的过程，但是当我们删除数据时，它会将这些数据转换成一个墓碑，并且会减慢压缩过程，这会使dse忙碌更长的时间，同时可能是scala作业试图与客户端请求一起运行。这可能是挂断dse进程。如果是这种情况，什么最适合删除旧数据
总数据负载与节点数：到目前为止，我们有近6tb的数据（复制因子为3）和15个dse节点（9个用于分析，6个用于solr）。我们需要添加一些额外的机器来处理节点吗
1条答案
按热度按时间5us2dqdw1#
回答您的一些问题：
1） 更改主机域-是否影响cassandra。通常不会。如果您在代码/联系点中使用主机名（如果正在使用证书，则可能是证书），则可能会出现这种情况。我不记得这是不是一个要求，但我们的yaml文件有ip地址，而不是主机名，所以这些不会受到影响。
2） 删除数据确实会影响处理和读取。它们中的很多会导致问题（压倒性的墓碑，堆恶化等）。如果你必须删除，你必须删除。如果您有时间序列类型的数据，我建议使用带有ttl的twcs进行删除，因为它解决了很多问题。否则，您将不得不处理可能出现的墓碑和压实问题。
3） 这个问题可能需要进一步澄清才能得到回答。您是否在每个dc上有6tb的数据（即在analytics dc上有6tb的数据，在solr dc上有6tb的数据）、总共6tb的数据（包括所有副本）（例如，3tb用于analytics，3tb用于solr）或在计算任何副本之前有6tb的数据（即包括副本时总共18tb）？
至于你最初关于注意到节点下降的陈述。你确定他们为什么要倒下了吗？Cassandra日志文件揭示了什么？在我们的环境中，如果一个节点发生故障，通常有以下几个原因：
1） gc问题-如果gc花费的时间太长，这可能会导致大问题，并最终导致节点失效。在system.log中查找“gcinspector”，了解gc需要多长时间。
2） 堆内存问题-dse的每个版本似乎消耗更多的内存，对于DSE6.x，您需要注意发生的一些yaml更改（一些配置更改现在默认为堆外，这将导致比以前版本更多的内存消耗）。在系统日志文件中，特别是在dse6.x（在我们的例子6.7中）中，我看到了许多“堆内存不足”的消息，这些消息占用了节点。如果您使用的是6.7.3并且您使用的是node sync，那么有一个已知的内存泄漏bug（我们遇到的）会导致这个问题。升级/修补至6.7.4。
3） o/s内存问题—我们有些环境内存不足—20gb，o/s启动oom killer释放内存，杀死dse和/或datastax代理（opscenter）。
这些是我多年来看到的主要原因，但系统日志文件中可能会显示出其他原因。
-吉姆