问题标签 [nodetool]

如果我们在 C* 环中添加了新节点，我们是否需要运行“nodetool cleanup”来清除现在已经分配到其他地方的数据？还是在正常压实期间无论如何都会发生这种情况？在正常压缩期间，C* 是否会删除不再属于该节点的数据，或者我们是否需要为此运行“nodetoool cleanup”？询问是因为“清理”需要永远并且在完成之前使节点崩溃。

如果我们需要运行“nodetool cleanup”，有没有办法找出哪些节点现在拥有不应再拥有的数据？（即现在属于新节点上的数据，但仍然存在于旧节点上，因为没有人将其删除。这是“nodetool cleanup”将删除的数据。）我们有 RF=3 和两个数据中心，每个其中有完整的数据副本。我假设我们需要在添加节点的数据中心中的所有节点上运行清理，因为新节点上的每一行曾经位于另一个节点（主节点）上，加上另外两个节点上的两个副本（副本）。

在尝试对我们的键空间中的一个列族进行 nodetool 修复时，需要帮助了解 Cassandra 发生了什么。

我们正在运行 Cassandra 2.0.7，并有一个用于索引系统中对象数据的表。

行可以增长到相当大。我们在数据库中大约有 1000 万个对象，平均有 4-6 个字段通过上表对它们进行索引。对我来说似乎并不多。

在运行 nodetool repair 时，我们会运行一段时间，然后遇到抛出以下异常的点：

此时，其他节点将无响应，抛出 TPStatus 日志并且基本上无响应。系统不会从中恢复。我们死了。

我在所有节点上运行并运行了“nodetool scrub”。这对他们中的大多数人都有效，有些失败了，所以我对他们使用了“sstablescrub”。我们编写了一个执行子范围修复的脚本，我可以识别出有问题的范围，但我还没有做足够的测试来知道这是一致的还是有症状的。当它降低生产时测试很困难，所以我必须小心。

侧边栏问题...您如何停止正在进行的维修？如果我能看到事情横向发展，我想阻止它。

请注意，键空间中的每个其他列族都可以正常修复。

我不确定要提供什么其他细节。一个星期以来，我们一直在为此苦苦挣扎，好吧，我们被困住了。

我有一个 2 节点 apache cassandra (2.0.3) 集群，rep 因子为 1。我在 cqlsh 中使用以下命令将 rep 因子更改为 2

然后我尝试在进行此类更改后运行推荐的“nodetool repair”。

问题是这个命令有时会很快完成。当它确实像那样完成时，它通常会说“丢失通知......”并且退出代码不为零。

所以我只是重复这个'nodetool repair'，直到它没有错误地完成。我还检查了“nodetool status”是否报告了每个节点的预期磁盘空间。（使用代表因子 1，每个节点都说每个节点大约 7GB，我希望在 nodetool 修复之后每个节点都是 14GB，假设同时没有集群使用）

在这种情况下，是否有更正确的方法来确定“nodetool repair”是否完成？

只想了解使用 Cassandra 2 在多数据中心设置中“nodetool repair”的性能。

我们计划在每个数据中心拥有 2-4 个副本的键空间。我们可能有几十个数据中心。根据情况，写入以 LOCAL_QUORUM/EACH_QUORUM 一致性完成，读取通常以 LOCAL_QUORUM 一致性完成。问题：

1. nodetool 修复复杂性是否随着所有数据中心的副本数量线性增长？

2. 还是 nodetool 修复复杂度会随着当前数据中心的副本数量和数据中心数量的组合而线性增长？模糊地说，这个模型可能会与当前数据中心的每个单独节点同步数据，但对其他数据中心的副本进行类似 EACH_QUORUM 的操作。

3. 要扩展集群，是在现有数据中心添加更多节点还是在假设整体副本数量不变的情况下添加新数据中心更好？我在 nodetool 修复性能的背景下问这个问题。

我计划建立一个多数据中心 Cassandra 2，每个数据中心有 2-4 个节点和几十个数据中心。我们在每个数据中心的一定数量的节点上复制了键空间。我们有一个基于 vnode 的部署。所以令牌应该自动分配给节点。

http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_add_node_to_cluster_t.html上的文档建议添加新节点需要在集群的所有其他节点上运行清理。但是，它没有阐明多数据中心设置中的过程。

我的理解是 nodetool cleanup 删除不再属于该节点的数据。当一个新的数据中心正在建立时，我们正在创建全新的副本和 AFAICT，它不会导致这个新数据中心之外的数据移动/重新平衡，因此对其他数据中心的节点没有清理要求。是否有人可以确认我的理解是否正确，并且不需要在其他数据中心的节点上进行清理？

当我使用以下命令时。
nodetool -h localhost -p 7199 cfstats demodb我想出了以下结果。我无法从以下结果得出任何结论。我无法确定我的两节点集群 Cassandra 性能是否良好或需要调整。

我正在将数据从 Cassandra 1.1.3 迁移到 1.2.13。我创建了列族的快照，并将其中的所有数据移动到新节点的每个列族目录中。

然后运行 ​​nodetool 的upgradesstables -a命令。然后我运行refresh <KS> <CF>命令，然后出现以下错误。

这里有什么问题？

谢谢，

我正在使用 cassandra-2.0.3，我在数据中心添加了一个新节点（使用 vnodes），但是在运行 nodetool cleanup 时我得到了

一段时间后，我尝试再次运行它并以 java.lang.AssertionError 结束。

上述异常的原因是什么？有什么快速的解决方案吗？

从文档中：

使用 nodetool repair -pr (--partitioner-range) 选项仅修复该节点的主要范围，该范围的其他副本仍然必须执行 Merkle 树计算，从而导致验证压缩。因为所有副本都在同时压缩，所以所有节点对那部分数据的响应可能很慢。

可能永远不会有任何时候我可以接受所有节点对数据的某个部分变慢。但我想知道：为什么这样做^{（或者可能只是与文档中的“-par”选项混淆？！）}，什么时候nodetool repair似乎更聪明：

默认情况下，repair 命令会立即对每个副本进行快照，然后从快照中顺序修复每个副本。例如，如果你有 RF=3 并且 A、B 和 C 代表三个副本，则此命令立即对每个副本进行快照，然后从快照中顺序修复每个副本（A<->B，A<->C， B<->C) 而不是一次性修复 A、B 和 C。这允许动态告密者通过其他副本来维护您的应用程序的性能，因为快照中至少有一个副本没有进行修复。

但是，datastax 博客解决了这个问题：

然而，这第一阶段可能在磁盘 io 上很密集。您可以通过压缩限制在一定程度上缓解这种情况（因为这个阶段就是我们所说的验证压缩。）有时这还不够，有些人试图通过使用 -pr (-partitioner-range) 来进一步缓解这种情况nodetool repair 的选项，它只修复该节点的主要范围。不幸的是，该范围的其他副本仍然必须执行 Merkle 树计算，从而导致验证压缩。这可能是一个问题，因为所有副本将同时执行此操作，这可能会使它们都响应您的那部分数据的速度变慢。幸运的是，使用 -snapshot 选项可以解决这个问题。

这可能很好，但实际上，没有-snapshot选项nodetool repair（请参阅联机帮助页或文档）（是否已删除此选项？！）

所以总的来说，

• 我似乎无法使用nodetool repair -pr，因为我总是需要至少保持系统足够响应以保持一致的 ONE 读/写，而不会出现明显延迟。（注意：我们只有一个数据中心。）还是我遗漏/误解了什么？
• 为什么nodetool repair聪明，让一个节点保持响应，同时nodetool repair -pr让所有节点对一部分数据变慢？
• 选项在哪里-snapshot：它是否已被删除，从未实现，或者它现在是否可以自动像这样工作，也在使用时nodetool repair -pr？

我有一个包含 9 TB 数据的 5 节点 cassandra 集群，并计划在集群中再添加 5 个节点。添加新节点后，负载平衡将开始，分区键的子范围将映射到新节点。我应该在什么时候进行 nodetool 清理。在启动新节点后立即进行 nodetool 清理是否会从集群中的旧节点中删除属于该子范围的旧数据。