我正在运行3节点的apachecassandra集群作为docker容器，其中包含45天ttl的timeseries数据。
我计划将当前的cassandra版本2.2.5升级到cassandra 3.11.4版本。为升级确定了以下步骤-
备份现有数据
刷新一个cassandra节点
bin/nodetool-h cassandra1-u CAU itoa-pw CAU itoa排水管
停止cassandra1节点
启动新的cassandra3.11.4容器
升级sstable
bin/nodetool-u ca\ u itoa-pw ca\ u itoa升级表
检查节点状态。对其余节点重复此过程
我对升级过程没有什么问题-
步骤正确吗？
运行upgradessstables命令是否可行。这很费时，我想看看能不能避免。数据已设置ttl。cassandra会继续以新的sstable格式写入，而旧的sstable数据会在过期时被清除吗？假设在45天后，所有sstable都将是新的闪亮格式。
2条答案
按热度按时间ego6inou1#
只是一些额外的想法：
对于第六步，你实际上不必跑
upgradesstables马上。事实上，如果您要升级生产系统，最好在应用程序团队验证他们可以正常连接之前不要升级。请记住，在2.2中运行的旧版本驱动程序可能无法与3.11.4一起运行。为此，我会等到整个集群都在新版本上运行之后再运行
upgradesstables在每个节点上。运行upgradessstables命令是否可行？
由于每个cassandra版本都能够读取自己的sstable格式以及之前的主要版本，我猜这不是强制性的。但这绝对是你应该做的。尤其是升级到3.x时。
Cassandra3包含对存储引擎的重大升级，其结果是磁盘占用空间小得多。我升级的一个集群的磁盘需求减少了90%。
另外，在读取可能分布在旧的sstable文件和新的sstable文件中的记录时，还将产生额外的延迟。跨多个文件读取记录已经够糟糕的了。但现在你要强迫Cassandra阅读和整理两种格式的结果。
所以，虽然我不会说这是“强制性的”，但我肯定会说这是一个“好主意”
eqzww0vc2#
是的，当您从2.2.x升级到3.11.4时，您需要在cassandra升级之后在每个节点上运行nodetool sstableupgrade。sstable文件格式和ext也将改变。您可以在后台运行此进程，它不会产生任何问题。更多详情请参考以下链接https://blog.thethings.io/upgrading-apache-cassandra-cluster/