在使用 Cassandra 的内部安全性时，您对 system_auth 使用什么复制因子？
较旧的文档似乎建议它应该是 N，其中 N 是节点数，而较新的文档建议我们应该将其设置为大于1.我可以理解为什么它更高是有意义的-如果发生分区并且一个部分没有副本，则没有人可以登录。
但是，它需要是所有节点吗？将其设置为所有 ndo 有什么缺点？
【问题讨论】：
标签： configuration cassandra replication
让我通过提出另一个问题来回答这个问题：
如果（由于某些不可预见的事件）您的所有节点都关闭了，除了一个；您还希望能够登录（并使用）该节点吗？
这就是为什么我确实确保我的 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 用户不再起作用。
在大小有波动趋势的集群上发现了这些缺点。当然，规模发生变化的集群通常这样做是因为多个提供商之间的高吞吐量要求，这使事情变得更加复杂。我们注意到，应用程序团队偶尔会报告此类集群上的身份验证失败。我们能够通过在所有system_auth 表上运行SELECT COUNT(*) 来快速纠正这些情况，从而强制进行读取修复。但下次我们添加/删除多个节点时，该问题往往会再次出现。
由于较大的集群可能会出现大小波动的问题，我们现在处理 system_auth 就像我们处理任何其他键空间一样。也就是说，我们设置@ 987654326@的RF到每个DC中的3个。
这似乎工作得很好。它可以帮助您解决在高吞吐量、动态环境中管理过多副本所带来的问题。毕竟，如果 RF=3 对您的应用程序数据来说足够好，那么对于 system_auth 来说可能就足够了。
【讨论】：
建议更改的原因是仲裁查询需要一半以上节点的响应才能完成。因此，如果您不小心让 Cassandra 用户处于活动状态并且您有 80 个节点 - 我们需要 41 个响应。
虽然避免使用这样的超级用户是一种很好的做法 - 你会惊讶于它仍然存在的频率。
【讨论】：