Configuration 用于系统验证的复制因子

在使用Cassandra的内部安全性时，您对system_auth使用什么复制因子

较旧的文档似乎建议它应该是N，其中N是节点数，而较新的文档建议我们应该将其设置为大于1的数字。我能理解为什么它更高是有意义的——如果一个分区出现，并且一个分区没有副本，那么没有人可以登录

---

但是，它是否需要是所有节点？将其设置为所有NDOE的缺点是什么？

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

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

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

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

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

如果您仍然对问题的这一部分感到疑惑：

较旧的文档似乎建议它应该是N，其中N是节点数，而较新的文档建议我们应该将其设置为大于1的数字。”

我今天在2.1文档中偶然发现了这一点：

将system_auth keyspace的复制因子增加到N （节点数）

只是要确保这个建议是明确的

附录20181108

因此，当我管理的最大集群有10个节点时，我最初回答了这个问题。四年后，在为一家大型零售商管理了三个大型（100多个）节点集群之后，我对此的看法有所改变。我可以说，我不再同意四年前我的这一说法

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

有几次，对于大型（20-50个节点）集群，我们部署了RFs高达8的

system\u auth

。只要不移动节点，并且假设默认的cassandra/cassandra用户不再使用，它就可以工作

缺点出现在大小有波动趋势的集群上。当然，大小变化的集群通常会这样做，因为跨多个提供商的高吞吐量要求，这使事情更加复杂。我们注意到，偶尔，应用程序团队会报告此类集群上的身份验证失败。我们能够通过在所有

system\u auth

表上运行

SELECT COUNT（*）

，快速纠正这些情况，从而强制执行读取修复。但是，在下次添加/删除多个节点时，问题可能会重新出现

由于较大的集群可能会出现大小波动的问题，我们现在将

与对待任何其他键空间一样对待。也就是说，我们在每个DC中将

system\u auth

的RF设置为3

---

这似乎非常有效。它帮助您解决了在高吞吐量、动态环境中管理太多副本所带来的问题。毕竟，如果RF=3对于应用程序的数据来说足够好，那么对于

system\u auth

来说就足够了。建议更改的原因是仲裁查询需要超过一半节点的响应才能完全填充。因此，如果您意外地让Cassandra用户处于活动状态，并且您有80个节点，那么我们需要41个响应

---

虽然避免像那样使用超级用户是一种很好的做法，但你会惊讶它仍然存在的频率。

是的……我可以看到。我想这只会成为大型集群的一个问题，其中奇数节点经常出现故障。看不到我们经常更改身份验证内容……不妨全部使用：）