Cassandra 在两分钟延迟内添加节点

你好，卡桑德拉宇宙的大师们

我是一个低级的devops工程师，试图解决一个我甚至不能清楚定义的问题，我需要一些洞察力

根据Cassandra（和）的文档，当您旋转新节点以加入现有集群时，需要在启动每个节点之间等待两分钟。没有解释为什么只需要两分钟，也没有解释不遵守这些指示的后果。在与支持Cassandra的团队交谈时，我被告知这可能会导致一个非常尴尬的场景，导致节点不能正确地拥有他们应该负责的数据（我对他们所说的非db摘要），这几乎是无法检测到的，并且是不可修复的（我们唯一已知的解决方案是构建一个新集群并迁移到该集群）。鉴于对问题的解释，我没有明确的方法来诊断存在的问题，同样也没有方法验证任何建议的解决方案。与此同时，我们的解决办法是启动时的粗略边缘延迟，这远非完美，但在理论上似乎可行

我的工作是处理服务器配置（使用Puppet），确保这种情况不会发生（如果确实存在问题的话）

所以我的问题是多方面的：

是否有人知道为什么正好是两分钟，或者有来自DataStax（或其他）的文档来澄清造成的确切问题

DevOps世界中是否有人为此而工作（使用厨师/木偶/其他工具）以防止这种情况发生（您做了什么？）

是否有人知道何时发生此问题的检测方法（以便我可以测试解决方案）

是否有人知道防止这种情况发生的方法（或查看节点当前是否正在加入，从而知道您必须等待的方法）

是否有人可以明确地说明为什么没有必要延迟？（这会使我的工作更容易，但我认为这不太可能）

---

谢谢您的帮助！

昨天我与DataStax的一位代表进行了讨论，结果得到了令人满意的答案

两分钟等待的原因是，当多个盒子同时旋转时，您可能（并且很可能会）以不平衡的数据分布结束（一些节点比其他节点获得更多负载）如果节点按顺序等待，则不会发生这种情况。由于节点没有意识到它们不再负责数据段，也可能导致不一致。可以通过重新分配令牌（手动）来修复数据责任，并且可以通过在环中的每个节点上运行“nodetool repair-pr”或仅运行“nodetool repair”来轻松修复不一致性。这可以纠正谁负责什么，并将数据放在需要的位置

另一个选项是，在旋转框时，保持auto_bootstrap=false，并手动（或稍后使用自动工具）将新节点加入集群

所以，向我报告的问题有点不正确，唯一真正的问题是可能导致不一致，并且是完全可以解决的

---

感谢您的回复，我希望这对其他人有所帮助。

关于“为什么延迟”。使用nodetool监控新节点的状态以决定何时继续（状态：加入）是否足够？我的理解（除了我为处理此任务所做的研究外，我对Cassandra并不熟悉）服务器必须启动（服务已启动）按照顺序，如果我使用nodetool进行监视，我仍然无法保证另一个节点不会同时尝试启动。但是，从您的说明来看，听起来我可以在不加入服务的情况下启动该服务，并等待直到没有其他框加入，然后触发加入。（从我读到的其他东西听起来似乎有点可能）。这是到这里的更好的路线吗？（我假设nodetool会打电话给监视器）你在使用vnodes吗？老实说，我不确定，因为我正在处理如何安装Cassandra并使用Puppet运行，我不知道一旦它启动，实际用户将如何使用它。所以我想最好的答案是：是和否，取决于我无法控制的选择。