用于system_auth的复制因子

Question

将内部安全性与Cassandra一起使用时，您对system_auth使用什么复制因子？

较旧的文档似乎建议将其设置为N，其中N是节点数，而较新的文档则建议将其设置为大于1的数字。我可以理解为什么将它设置为更高是有意义的-如果a发生分区，并且一个部分没有副本，没有人可以登录。

但是，是否需要所有节点？将其设置为所有ndo的不利之处是什么？

Answer 1

让我提出另一个问题来回答这个问题：

如果（由于某些不可预见的事件）您的所有节点都崩溃了，除了一个节点之外；您是否仍然希望能够登录（并使用）该节点？

这就是为什么我确实要确保将system_auth密钥空间复制到我的所有节点。您无法预测节点故障，并且为了保持您的应用程序运行，安全起来总比对不起好。

我认为这样做没有任何明显的弊端。system_auth密钥空间不是很大（我的是20kb），因此它不会占用很多空间。唯一可能的情况是，如果其中一个节点发生故障，并且对system_auth中的列族进行了写操作（在这种情况下，我认为写操作会被拒绝……取决于您的写一致性）。不管哪种方式，system_auth都不是非常繁重的键空间。因此，只要您不计划在节点故障期间执行用户维护，就可以了。

将system_auth的复制因子设置为群集中的节点数应该可以。至少，我要说的是，您应该确保将其复制到所有数据中心。

如果您仍然想知道问题的这一部分：

较早的文档似乎建议将其设置为N，其中n是节点数，而较新的文档则建议将其设置为大于1的数字。”

我今天在2.1文档配置身份验证中偶然发现了这一点：

将system_auth密钥空间的复制因子增加到N（节点数）。

只要确保该建议是明确的。

附录20181108

因此，当我曾经管理的最大群集具有10个节点时，我最初对此做了回答。四年后，在将其中三个管理大型（100+）节点集群的服务器投入大型零售商之后，我对此的看法有所改变。我可以说，我不再同意我四年前的这一说法。

这就是为什么我确实要确保将system_auth密钥空间复制到我的所有节点。

在大型（20-50个节点）集群上，我们已经部署system_auth了几次RF，频率高达8。只要您不移动节点，就可以正常工作，并且假定默认的cassandra / cassandra用户为不再在游戏中。

集群的大小有波动的趋势，这是其缺点。当然，大小变化的集群通常会这样做，因为跨多个提供程序的吞吐量要求很高，这使事情变得更加复杂。我们注意到，有时应用程序团队会报告此类群集上的身份验证失败。通过SELECT COUNT(*)在所有system_auth表上运行，我们能够快速纠正这些情况，从而强制进行读取修复。但是，下一次我们添加/删除多个节点时，问题往往会浮出水面。

由于较大的集群可能会发生问题，这些集群的大小会发生波动，因此我们现在将其视为 system_auth 与其他任何键空间一样。 也就是说，我们system_auth在每个DC 中将的RF 设置为3。

这看起来真的很好。它解决了在高吞吐量，动态环境中管理太多副本所带来的问题。毕竟，如果RF = 3对于您的应用程序数据而言足够好，那么对于来说可能就足够了system_auth。