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

Question

• 1个群集，3个节点，分布在2个物理位置，分为2个机架
• RF 2
• PropertyFileSnitch
• CL QUORUM

问题是：

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

如果我启动第三个节点并关闭第二个节点，则读取和写入工作。

第二个和第三个节点都复制到第一个节点，如果第一个节点关闭，则读取和写入也会失败。

问题是：

是否可以自动检测死节点并将复制点指向活动的检测节点？

• 如果第一个节点关闭，第二个和第三个节点在彼此之间复制数据
• 如果第二个或第三个节点关闭，第一个节点应该检测到什么是活动的并复制到它

的 UPDATE1： 的

做了一些测试：

• 关闭第一个节点 - 从第二个和第三个节点读取失败（Unable to complete request: one or more nodes were unavailable.）
• 关闭第二个节点 - 从第一个和第三个节点读取
• 关闭第三个节点 - 从第一个和第二个节点读取失败

很奇怪......

的 UPDATE2： 的

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

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

我是对的吗？

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

的 UPDATE3： 的

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

Answer 1

从截图中可以看出它是Opscenter。

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

现在开始关注节点下降＆amp;读写失败，基本上这些东西取决于读/写一致性级别。通过一致性级别，您将能够自己找到解决方案。

<强>更新

可能你会发现这个blog很有趣。 Cassandra失败的唯一时间是当协调员收到请求时，很少有副本存活。这可能是你的奇怪情况背后的原因

Answer 2

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