如何解决cassandra 3.11.9 system_auth 在生产环境中需要是 SimpleStrategy 或 NetworkTopologyStrategy 吗？
cassandra (apache) 3.11.9 system_auth 推荐什么？需要是 SimpleStrategy 还是 NetworkTopologyStrategy？需要多少射频？
我们有 1 dc 的 cassandra（2-3 个 AWS 机架，EC2_snitch + dynamic_snitch 被禁用）。大多数查询在一致性级别 local_one 上运行）。今天我们的 system_auth 键空间使用 RF 3 配置 SimpleStrategy。在很多查询中，我们都在浪费时间（跟踪）：
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 密钥空间配置有关？
解决方法
我前段时间回答过这个问题，类似的： 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 上执行。也可能是查询一致性和连接一致性设置不同。只是一个想法。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
