cassandra 机架复制固定到（死）节点 [RF 和 CL 混淆]

Question

• 1 个集群，3 个节点，位于 2 个物理位置，分在 2 个机架中
• 射频 2
• PropertyFileSnitch
• CL 法定人数

问题是：

第一个节点（在 RAC1 中）的复制从 RAC2 指向第三个节点，如果该节点关闭、读取和写入失败，则不会更改。

如果我重新启动第三个节点并关闭第二个节点，则读写工作正常。

第二个和第三个节点都复制到第一个节点，如果第一个节点宕机，读写也会失败。

问题是：

是否可以让它自动检测死节点并将复制点复制到活动检测节点？

• 如果第一个节点宕机，第二个和第三个节点相互复制数据
• 如果第二个或第三个节点宕机，第一个节点应该检测到什么是活动的并复制到它

更新 1：

做了一些测试：

• 关闭第一个节点 - 从第二个和第三个节点读取失败 (Unable to complete request: one or more nodes were unavailable.)
• 关闭第二个节点 - 从第一个和第三个节点读取工作正常
• 关闭第三个节点 - 从第一个和第二个节点读取失败

很奇怪……

更新 2：

我想我找到了答案。现在情况如何：3 个节点，RF 2，写入和读取具有 CL 2。如果一个副本关闭，则读取和写入失败（我测试选择不同的密钥，一些在一个节点关闭时成功，而在另一个节点关闭时失败）

现在我正在考虑这样做：将所有节点移动到一个机架，将 RF 更改为 3，对于读取和写入，我将使用 CL 2（写入成功需要两次复制，第三次将在后台进行）。所以现在会有 3 个副本，如果一个失败，CL 2 无论如何都会成功。

我说的对吗？

如果有 2 个节点处于活动状态，复制因子为 3，当前写入操作的一致性级别为 2，写入会成功吗？

更新3：

是的，我认为我的方法是正确的。 Same question here

Answer 1

从屏幕截图可以假设它是 Opscenter。

在 Opscenter 中有一个称为警报的特殊功能。它将帮助您检测死节点。

现在谈到节点宕机和读写失败的问题，基本上这些事情取决于读/写一致性级别。通过一致性级别，您将能够自己找到解决方案。

更新：

您可能会觉得blog 很有趣。 Cassandra 失败的唯一一次是当协调器收到请求时，存活的副本太少。这可能是你的奇怪情况背后的原因

Answer 2

您希望 RAC1 中的所有三个节点的复制因子为 3，并使用 QUORUM 进行读/写。这将确保数据始终持久化到两个节点，读取将保持一致，并且可以有一个故障节点而不会停机或数据丢失。如果您不关心读取始终保持一致，即有时允许使用陈旧数据，您可以使用 ONE 进行读取来提高读取性能。