在Cassandra中使用内部安全性时，您对system_auth使用什么复制因子？
较旧的文档似乎表明它应该是 N ，其中 N 是节点的数量，而较新的文档建议我们应该将它设置为大于1.我能理解为什么它更高是有意义的 - 如果一个分区出现而且一个部分没有副本，那么没有人可以登录。
但是，它需要是所有节点吗？将它设置为所有ndo的缺点是什么？
答案 0 :(得分：4)
让我通过提出另一个来回答这个问题：
如果（由于一些不可预见的事件）所有节点都发生故障，除了一个;你还想要能够登录（并使用）那个节点吗？
这就是为什么我确实确保我的system_auth键空间复制到我的所有节点。您无法预测节点故障，为了保持您的应用程序正常运行，它比抱歉更安全。
我没有看到这样做有任何明显的缺点。 system_auth键空间不是很大（我的是20kb）所以它不会占用大量空间。唯一可能的情况是，如果其中一个节点关闭，并且对system_auth中的列族进行了写操作（在这种情况下，我认为写入被拒绝......取决于您的写入一致性）。无论哪种方式，system_auth都不是一个非常重写的密钥空间。只要您不打算在节点故障期间执行用户维护，那么您就可以了。
将system_auth的复制因子设置为群集中的节点数应该没问题。至少，我会说你应该确保它复制到你的所有数据中心。
如果你仍然想知道你问题的这一部分：
较旧的文档似乎表明它应该是N，其中n是节点数，而较新的文档建议我们应该将它设置为大于1的数字。“
我今天在2.1文档Configuring Authentication中偶然发现了这一点：
将system_auth键空间的复制因子增加到N. （节点数）。
确保推荐清楚。
附录20181108
所以当我管理的最大集群有10个节点时，我最初回答了这个问题。四年后，在为一家大型零售商管理大型（100多个）节点集群中的三个之后，我对此的看法发生了一些变化。我可以说我不再同意四年前的这一陈述。
这就是为什么我确实确保我的system_auth键空间复制到我的所有节点。
在思维到大型（20-50个节点）的集群中，我们已经部署了system_auth，其RF高达8个。只要您不移动节点，它就会工作，并假设默认的cassandra / cassandra用户不再使用。
在具有大小波动倾向的簇上看到了缺点。当然，尺寸变化的集群通常会这样做，因为跨多个提供商的吞吐量要求很高，这使事情变得更加复杂。我们注意到，应用程序团队偶尔会在此类集群上报告auth失败。通过在所有SELECT COUNT(*)表上运行system_auth，我们能够快速纠正这些情况，从而强制进行读取修复。但是，下次我们添加/删除多个节点时，问题会重新出现。
由于较大群集的大小可能会出现问题，我们现在将 system_auth 视为我们执行任何其他键空间。也就是说，我们在每个DC中将system_auth的RF设置为3。
这似乎工作得很好。它可以帮助您解决在高吞吐量，动态环境中管理太多副本所带来的问题。毕竟，如果RF = 3足以满足您应用程序的数据，那么对于system_auth来说它可能已经足够了。
答案 1 :(得分：2)
建议更改的原因是仲裁查询将需要来自一半以上节点的响应才能完全填充。因此，如果您不小心使Cassandra用户处于活动状态，并且您有80个节点-我们需要41个响应。
避免使用这样的超级用户是一个好习惯，但您会惊讶它仍然存在的频率。