cassandra 3.11.9 system_auth 需要在生产环境中使用 SimpleStrategy 或 NetworkTopologyStrategy？

Question

cassandra (apache) 3.11.9 system_auth 推荐什么？需要SimpleStrategy 或NetworkTopologyStrategy？用多少射频？

我们有 1 个 dc 的 cassandra（2-3 个 AWS 机架，禁用了 EC2_snitch + dynamic_snitch）。大多数查询在一致性级别 local_one 上运行）。今天我们的system_auth 键空间配置了SimpleStrategy 与RF 3。在很多查询中，我们在（跟踪）上浪费时间：

Executing single-partition query on roles [ReadStage-X]

为了解决我们的问题，我们还增加了参数：

roles_validity_in_ms、permissions_validity_in_ms、credentials_validity_in_ms、permissions_cache_max_entries。

查询延迟问题能否与 system_auth 键空间配置相关联？

Answer 1

我刚才回答了这个问题，类似： Replication Factor to use for system_auth

由于较大的集群可能会出现大小波动的问题，我们现在像对待任何其他密钥空间一样对待 system_auth。也就是我们在每个 DC 中将 system_auth 的 RF 设置为 3。

tl;dr;，如果您在非系统键空间上使用NetworkTopologyStrategy，那么您也应该将它用于system_auth。与您的射频相同；我总是将system_auth 的 RF 与我的“正常”键空间的 RF 匹配。

不，system_auth 上使用的复制策略和 RF 通常不会导致查询延迟。当然，除非已更改任何安全缓存设置。与 Cassandra 合作 10 年，我从未改变过这些：https://docs.datastax.com/en/security/5.1/security/secAuthCacheSettings.html

在（跟踪）上浪费时间的查询：“对角色执行单分区查询 [ReadStage-X]”

这句话让我想到：您是否在以默认cassandra 用户身份登录时在 cqlsh 中跟踪查询？该用户确实触发了一些 cqlsh 操作以在 QUORUM 处执行。也可能是查询一致性和连接一致性设置不同。只是一个想法。