cassandra 3.11.9 system_auth 需要在生产环境中使用 SimpleStrategy 或 NetworkTopologyStrategy？
cassandra 3.11.9 system_auth need to be SimpleStrategy or NetworkTopologyStrategy on production env?
推荐的 cassandra (apache) 3.11.9 system_auth 是什么？需要 SimpleStrategy 还是 NetworkTopologyStrategy？ RF 有多少？
我们有 1 个 dc 的 cassandra（2-3 个 EC2_snitch + dynamic_snitch 禁用的 AWS 机架）。大多数查询 运行 一致性级别 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 键空间配置有关？
前阵子回答过这个问题，类似：
Replication Factor to use for system_auth
Due to issues that can happen with larger clusters which fluctuate in size, we now treat system_auth like we do any other keyspace. That is, we set system_auth's RF to 3 in each DC.
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
queries wasting time on (tracing): "Executing single-partition query on roles [ReadStage-X]"
这句话让我开始思考：您是否在以默认 cassandra 用户身份登录时在 cqlsh 中跟踪查询？该用户 确实 触发了一些 cqlsh 操作以在 QUORUM 执行。也可能是查询一致性和连接一致性设置不同。只是一个想法。
推荐的 cassandra (apache) 3.11.9 system_auth 是什么？需要 SimpleStrategy 还是 NetworkTopologyStrategy？ RF 有多少？
我们有 1 个 dc 的 cassandra（2-3 个 EC2_snitch + dynamic_snitch 禁用的 AWS 机架）。大多数查询 运行 一致性级别 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 键空间配置有关？
前阵子回答过这个问题，类似： Replication Factor to use for system_auth
Due to issues that can happen with larger clusters which fluctuate in size, we now treat system_auth like we do any other keyspace. That is, we set system_auth's RF to 3 in each DC.
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
queries wasting time on (tracing): "Executing single-partition query on roles [ReadStage-X]"
这句话让我开始思考：您是否在以默认 cassandra 用户身份登录时在 cqlsh 中跟踪查询？该用户 确实 触发了一些 cqlsh 操作以在 QUORUM 执行。也可能是查询一致性和连接一致性设置不同。只是一个想法。