cassandra - 我可以在运行更新版本的新节点中升级 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（含）之间的更改日志，没有看到任何看起来像传输协议的重大重大更改的内容。

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

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

编辑：在 apache slack 的频道上来回一些后#cassandra，看起来好像没有这个过程的问题。然而，其他一些自动化因素导致的其他一些合并问题确实威胁到集群的数据完整性。简而言之，每个新节点seed也将 ITSSELF 添加到节点列表中。这可以在日志中看到：This node will not auto bootstrap because it is configured to be a seed node.

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

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

标签： cassandraupgradecassandra-3.0operation

Answer 1

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

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

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