我有一个 6 个节点的生产 cassandra 集群。我对一个节点上的 cassandra.yaml 文件进行了一些更改，因此需要重新启动它。 如何在不丢失任何数据或导致任何集群相关问题的情况下做到这一点？ 我可以杀死该特定节点上的 cassandra 进程并重新启动它吗？ 集群信息： 6个节点。都活跃。 我正在使用 AWS Ec2Snitch。
谢谢。
【问题讨论】：
标签： amazon-web-services cassandra cassandra-2.1
如果您使用大于 1 的复制因子，并且未对写入/读取使用所有一致性设置，则可以执行下面列出的步骤，而不会造成任何停机/数据丢失。如果您有上面列出的限制之一，您需要在继续之前提高复制因子/更改请求的一致性。
在 Cassandra 中，如果启用了持久写入，则无论如何您都不应该丢失数据 - 在意外重启的情况下，有一个 commitlog 日志重播机制，所以如果只是重启，您不应该丢失任何数据，但重播 commitlog 可能需要一些时间时间。
上面写的步骤是官方升级程序的一部分，应该是“最安全”的选项。您可以执行 nodetool flush + 重启，这将确保提交日志重播将最小化，并且可以比 drain 方法更快。
【讨论】：
nodetool describecluster 在不同节点上显示不同架构版本的问题。我一个节点一个节点地按照你的 3 个步骤进行操作。但只有在nodetool status 显示节点再次启动后，我才在下一个节点上执行了 3 个步骤
我可以直接终止该特定节点上的 cassandra 进程并重新启动它吗？
基本上，是的。我假设您的 RF 为 3 和 6 个节点，所以这应该没什么大不了的。如果您愿意，要执行我所说的“干净关机”，您可以先运行以下命令：
nodetool disablegossip
nodetool drain
然后（取决于您的安装）：
sudo service cassandra stop
或者：
kill `cat cassandra.pid`
请注意，如果您没有完成这些步骤，您应该仍然可以。 drain 只是将内存表刷新到磁盘。如果这没有发生，提交日志将与启动时磁盘上的内容进行核对。这些步骤只会让您的启动速度更快。
【讨论】：