我可以在运行更新版本的新节点中升级 Cassandra 集群吗？

Question

我对 Cassandra 比较陌生……作为用户和操作员。不是我被聘用的，但它现在在我的盘子里。如果有明显的答案或我遗漏的细节，我将非常乐意提供......请告诉我！

---

我找不到任何近期或具体的文档来明确说明在将具有更高 Cassandra 版本的节点引入现有集群时 Cassandra 节点的容忍度。

假设，假设我在运行 3.0.16 的集群中有 4 个节点，我想将集群升级到 3.0.24（发布时的最新版本；2021-04-19）。由于此处不重要的原因，不可能在每个现有节点上运行“就地”升级。也就是说：我不能简单地在现有节点上停止 Cassandra，然后执行nodetool drain; service cassandra stop; apt upgrade cassandra; service cassandra start。

我查看了 3.0.17 和 3.0.24（含）之间的 change log，没有看到任何看起来像传输协议的重大突破性变化的东西。

所以我的问题是：我能否将新节点（运行 3.0.24）引入 c* 集群（由 3.0.16 节点组成），然后在每个 @ 上运行 nodetool decommission 987654327@节点执行“一对一”replacement升级集群？

我是否会在此过程中冒任何数据完整性问题的风险？是否有特定原因导致上述程序不起作用？如果每个节点负责的令牌数量随着新节点的增加而增加呢？例如：0.16 节点在 128 令牌上平均分割键空间，但新节点 0.24 将在 256 令牌中分割所有内容。

编辑：在 apache slack 上的 #cassandra 频道上进行一些来回操作后，似乎该过程没有问题。然而，还有其他一些由其他部分自动化引起的共存问题确实威胁到了集群的数据完整性。简而言之，每个新节点都将 ITSSELF 添加到 seed 节点列表列表中以及。这可以在日志中看到：This node will not auto bootstrap because it is configured to be a seed node.

每个新节点都无法引导，但没有失败进行新的写入。

EDIT2：我不是在 k8s 环境中；这是“基本”EC2。同样，数据量/节点大小非常小；从几十兆字节到几百演出不等。在所有情况下，集群都少于 10 个节点。我上面概述的案例是针对一个测试/开发集群，它通常是两个不同机架/可用区中的 2 个节点，集群中总共有 4 个节点。

Answer 1

运行引导和停用将需要相当长的时间，特别是如果您有大量数据 - 您会将所有数据流式传输两次，这会增加集群的负载。更简单的解决方案是通过将旧节点的数据复制到与旧节点具有相同配置但具有不同 IP 和 3.0.24 的新节点来替换旧节点（不要启动该节点！）。分步说明在 this answer 中，如果正确完成，您将有最少的停机时间，并且无需等待引导程序停用。

如果您无法停止运行节点的另一种可能性是将所有新节点添加为new datacenter，调整复制因子以添加它，使用nodetool rebuild 强制将数据复制到新的 DC，将应用程序切换到新的数据中心，然后decommission the whole data center 不流式传输数据。在这种情况下，您将只流式传输数据一次。另外，如果新节点有不同数量的num_tokens会更好玩——不建议在同一个DC的节点上有不同的num_tokens。

附：当你有不同版本的节点时，通常不建议对集群拓扑进行更改，但对于 3.0.16 -> 3.0.24 可能没问题。

Answer 2

呼应 Alex 的回答，3.0.16 和 3.0.24 仍然使用相同的 SSTable 文件格式，因此升级的复杂性大大降低。他们仍然能够在不同版本之间传输数据，因此您的想法应该可行。如果您在类似 K8s 的环境中，使用新版本重新部署并将旧卷附加到替换实例可能会更容易。

“如果每个节点负责的令牌数量随着新节点的增加而增加呢？例如：0.16 个节点将密钥空间平均分为 128 个令牌，但新节点 0.24 会将所有内容分为 256 个令牌。”

关于这一点，我突然想到了几点。

首先，社区普遍认为num_tokens的默认值256太高了。即使是128也太高了。我会推荐一些 12 到 24 的东西（我们使用 16）。

我肯定不会增加它。

其次，更改 num_tokens 需要重新加载数据。原因是令牌范围发生了变化，因此每个节点对特定数据的责任发生了变化。我以前通过建立一个新的逻辑数据中心，然后切换到它来改变这一点。但我建议不要尽可能地改变它。

“简而言之，每个新节点也将 ITSSELF 添加到种子节点列表中。”

因此，虽然不建议这样做（每个节点都是种子节点），但它并不是一个阻碍因素。您当然可以在之后运行 nodetool 修复/重建以将数据流式传输给它们。但是，是的，如果您能弄清楚为什么每个节点都将自己添加到种子列表中，那将是理想的。