【发布时间】：2015-09-04 13:01:12
【问题描述】：
我有一个 Cassandra 集群正在运行：
卡桑德拉 2.0.11.83 | DSE 4.6.0 | CQL 规范 3.1.1 | Thrift 协议 19.39.0
集群有 18 个节点，分布在 3 个数据中心，每个数据中心 6 个。我的 system_auth 键空间定义了以下复制：
复制 = { 'class': 'NetworkTopologyStrategy', 'DC1'：'4'， 'DC2'：'4'， 'DC3': '4'}
我的身份验证器/授权器设置为：
身份验证器：org.apache.cassandra.auth.PasswordAuthenticator
授权人：org.apache.cassandra.auth.CassandraAuthorizer
今天早上我关闭了 DC1 中的一个节点进行维护。在几秒钟/分钟内，客户端应用程序开始记录异常，如下所示：
“用户 my_application_user 对其父级或其任何父级没有修改权限”
在其他节点之一上运行“列出 my_application_user 的所有权限”表明用户在键空间 xxxxx 上有 SELECT 和 MODIFY，所以我很困惑。我有设置问题吗？这是某种错误吗？
【问题讨论】：
-
您需要确保还增加了 dse_security 的复制因子，然后在两个密钥空间上运行 nodetool repair（参考：Configuring system_auth and dse_security keyspace replication | DataStax Enterprise 4.7 Documentation）。
-
谢谢 BrianC。我检查了一下，似乎没有那个键空间——我唯一拥有的（除了用户创建的）是：“system dse_system system_auth system_traces”。这个集群曾经一度在 DSE 4.0.1 上，后来升级到 4.6.0，所以也许这就是为什么？ dse_system ks 用 EverywhereStrategy 的 rep 设置，system ks 用 LocalStrategy 设置。所有其他人都使用 NetworkTopologyStrategy。我错过了什么？再次感谢您的回复！
-
要检查的两件事是所有这些键空间在每个 DC 中都具有足够的复制需要。您为 system_auth 显示的那个很好，任何使用 EverywhereStrategy 的都很好（它会自动发生）。然后第二件事是在更改 RF 后对所有节点上的这些键空间进行 nodetool 修复。我不知道这是否是您的问题，但这就是我要开始的地方。您是否也尝试过对每个节点进行“列出所有权限”检查以确保它们都同意？
-
嗨，BrianC，感谢您的支持。 :) 集群运行 OpsCenter 修复服务，自上次更改用户名/密码以来，它已完成至少 3-4 次修复遍，自上次更改 RF 以来甚至更多。我还测试了在每个节点上以该用户身份登录（通过 'cqlsh LocalNodeIP -u my_application_user -p user_pass -f commands_file_containing_list_all_permissions_for_user' 并且它可以很好地登录到所有节点并且他们同意权限。我将尝试在system_auth KS，看看情况如何。还有其他 KS 吗？
-
顺便说一句，我的最终目标是停用一半的节点，而给我带来问题的节点（在我将其关闭以进行维护时导致登录失败）是计划停用的节点之一，所以我需要弄清楚交易是什么，然后再用核弹击中自己的脚。 :(