cassandra，在添加新节点期间构建的二级索引将永久持续

Question

我正在尝试向我们的群集添加新节点（cassandra 2.1.11,16个节点，32Gb ram，2x3Tb硬盘，8核cpu，1个数据中心，2个机架，每个节点上大约700Gb的数据）。在新节点启动后，来自16个现有节点的数据（总共大约600Gb）成功转移到新节点并开始构建二级索引。二级索引构建的过程看起来很正常，我看到有关成功完成某些二级索引构建和一些流任务的信息：

INFO  [StreamReceiveTask:9] 2015-11-22 02:15:23,153 StreamResultFuture.java:180 - [Stream #856adc90-8ddd-11e5-a4be-69bddd44a709] Session with /192.168.21.66 is complete

INFO  [StreamReceiveTask:9] 2015-11-22 02:15:23,152 SecondaryIndexManager.java:174 - Index build of [docs.docs_ex_pl_ph_idx, docs.docs_lo_pl_ph_idx, docs.docs_author_login_idx, docs.docs_author_extid_idx, docs.docs_url_idx] complete

根据日志显示，16个流中有9个成功完成。一切都很好，除了一个问题：这个过程已经持续了整整5天。除了进度极慢之外，日志中没有错误，没有任何可疑之处。

nodetool compactionstats -H

显示

   Secondary index build   ...    docs    882,4 MB   1,69 GB   bytes     51,14%

所以有一些建立指数的过程，它有一些进展，但很慢，1个半小时左右。

新节点和任何现有节点之间唯一显着的区别是cassandra java进程有21k个打开文件，而现有节点上有300个打开文件，而新节点上数据目录中有80k个文件。任何现有节点上数据目录中300-500个文件的对比。

这是正常的吗？在这个速度下，它看起来我将花费16周左右来增加16个节点。

Answer 1

我知道这是一个老问题，但我们使用DTCS遇到了2.1.13这个问题。我们能够在我们的测试环境中通过将可记忆的刷新阈值增加到0.7来修复它 - 这对我们没有任何意义，但可能值得尝试。