【问题标题】：Cassandra Upgrade limitationsCassandra 升级限制
【发布时间】：2017-06-03 17:25:35
【问题描述】：
我们正在 10 节点 PRODUCTION 集群中从 DSE 4.5 升级到 DSE 4.8.9。
我们的应用程序中每天运行批处理作业，这些作业批量加载集群中的数据，一些作业截断表并加载新数据，以及一些持续插入数据的加载程序作业。
考虑这些场景：
案例 1：
假设我的一个节点安装了 DSE 4.8，但 upgradesstables 正在运行。
此时所有节点都在线并且存在 2 个不同的模式（dse4.5 上的 9 个节点和 dse4.8.9 上的 1 个节点）。
在这种情况下，TRUNCATE 会起作用吗？
案例 2：
我的一个节点已完全升级到 DSE 4.8 ，这使我的集群处于部分升级状态，所有节点都在线，存在 2 个架构（DSE 4.5 上有 9 个节点，DSE 4.8 上有 1 个节点）。
在这种情况下 TRUNCATE 会起作用吗？
请提出建议。
谢谢！
【问题讨论】：
标签：
cassandra
datastax
cql
cassandra-2.0
datastax-enterprise
【解决方案1】：
不建议在升级期间发出TRUNCATE 命令，这是here 概述的限制之一
引用链接：
不要启用新功能。
不要运行 nodetool repair。
在滚动重启期间不要发出这些类型的 CQL 查询：DDL
并截断。
在升级过程中，不同版本的节点可能会显示一个架构
分歧。
在需要时未能升级 SSTables 会导致显着
性能影响和增加的磁盘使用率。升级未完成
直到升级 SSTables。
【解决方案2】：
应该首先在所有节点上升级二进制文件，以便我们在整个集群中拥有一个架构。
在所有节点完成运行“upgradesstables”之前避免使用 TRUNCATE。
markc 给出的评论也需要注意：
不要启用新功能。
不要运行 nodetool repair。
在滚动重启期间不要发出这些类型的 CQL 查询：DDL 和 TRUNCATE。
在升级过程中，不同版本的节点可能会出现架构不一致的情况。
在需要时未能升级 SSTable 会导致显着的性能影响和磁盘使用量增加。在升级 SSTable 之前，升级不会完成。