我可以在cassandra节点升级（3.0.15到4.1）过程中使用nodetool Resetlocalschema来解决3.x和4.x之间的架构不匹配问题吗

Question

最近我尝试以滚动升级方式将我的 cassandra 集群（3 + 3）从 cassandra 3.0.15 升级到 4.1.0，我发现当具有旧版本 cassandra 的节点充当协调器时，它无法从 cassandra 读取数据新版本的 cassandra，反之亦然。所以在升级过程中出现了巨大的不一致。我认为它的发生是因为 C3 和 C4 之间的架构不匹配。

因此，要解决这个问题，我可以在 cassandra 节点升级（3.0.15 到 4.1）过程中使用 nodetool Resetlocalschema 来解决 3.x 和 4.x 之间的架构不匹配问题。

提出消除停机时间的解决方案。

Answer 1

主要升级期间的 Cassandra 集群 应该有 2 个不同的架构版本，每个 Cassandra 版本一个。

据我所知，这并不意味着协调器无法从不同模式版本的节点中读取数据，除非正在读取的键空间/表是在版本之间发生变化的本机模式组件 - 例如用于虚拟的

system_views

Cassandra 4 中的表。您是如何发现不同版本的节点之间存在分区的？

除非您确实遇到架构不匹配的问题 - 在这种情况下，您应该在

nodetool describecluster

中看到 3 个或更多架构版本 - 一旦所有节点都升级，架构不匹配就应该得到解决，并且

nodetool resetlocalschema

不应该执行任何操作，直到然后，我仍然建议不要运行它。

同时，在升级完成之前，请不要进行任何 DDL 更改（

ALTER

、

CREATE

、

DROP

），否则可能会导致架构不匹配的实际问题。