configuration - 用于 system_auth 的复制因子

Question

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

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

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

Answer 1

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

如果(由于某些不可预见的事件)您的所有节点都出现故障，除了一个；您仍然希望能够登录(并使用)该节点吗？

这就是为什么我确实确保我的 system_auth key 空间复制到我的所有节点。您无法预测节点故障，为了保持应用程序运行，安全总比后悔好。

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

将 system_auth 的复制因子设置为集群中的节点数应该没问题。至少，我会说你应该确保它复制到你所有的数据中心。

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

The older docs seem to suggest it should be N where n is the number of nodes, while the newer ones suggest we should set it to a number greater than 1."

我今天在 2.1 文档中偶然发现了这个 Configuring Authentication :

Increase the replication factor for the system_auth keyspace to N (number of nodes).

只是确保建议是明确的。

附录20181108

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

This is why I actually do ensure that my system_auth keyspace replicates to all of my nodes.

几次在大型(20-50 个节点)集群上，我们已经部署了 system_auth RF 高达 8。只要您不移动节点，它就可以工作，并假设默认的 cassandra/cassandra 用户不再参与。

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

由于较大的集群可能会出现大小波动的问题， 我们现在治疗 system_auth 就像我们做任何其他键空间一样。 也就是说，我们设置 system_auth每个 DC 的 RF 为 3。

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