用于system_auth的复制因子 [英] Replication Factor to use for system_auth

问题描述

将内部安全性与Cassandra一起使用时，您对system_auth使用什么复制因子？

When using internal security with Cassandra, what replication factor do you use for system_auth?

较早的文档似乎建议它应为 N ，其中 N 是节点数，而较新的节点建议将其设置为大于1的数。我可以理解为什么将它设置为更高数是有意义的-如果发生分区并且一个部分没有副本，没有人可以登录。

The older docs seem to suggest it should be N, where N is the number of nodes, while the newer ones suggest we should set it to a number greater than 1. I can understand why it makes sense for it to be higher - if a partition occurs and one section doesn't have a replica, nobody can log in.

但是，它是否需要所有节点？

However, does it need to be all nodes? What are the downsides of setting it to all ndoes?

推荐答案

让我通过摆出另一个问题来回答这个问题：

Let me answer this question by posing another:

如果（由于某些不可预见的事件）您所有的节点都崩溃了，除了一个节点之外；您是否仍然希望能够登录（并使用）该节点？

If (due to some unforseen event) all of your nodes went down, except for one; would you still want to be able to log into (and use) that node?

这就是为什么我实际上要确保将system_auth密钥空间复制到我的所有节点。您无法预测节点故障，为了保持应用程序的运行，总比后悔安全。

This is why I actually do ensure that my system_auth keyspace replicates to all of my nodes. You can't predict node failure, and in the interests of keeping your application running, it's better safe than sorry.

我认为这样做没有任何明显的弊端。 system_auth密钥空间不是很大（最小为20kb），因此不会占用太多空间。唯一可能的情况是，如果其中一个节点发生故障，并且对system_auth中的列族进行了写操作（在这种情况下，我认为写操作会被拒绝……取决于您的写一致性）。不管哪种方式，system_auth都不是非常繁重的键空间。因此，只要您不打算在节点故障期间执行用户维护，就可以了。

I don't see any glaring downsides in doing so. The system_auth keyspace isn't very big (mine is 20kb) so it doesn't take up a lot of space. The only possible scenario, would be if one of the nodes is down, and a write operation is made to a column family in system_auth (in which case, I think the write gets rejected...depending on your write consistency). Either way system_auth isn't a very write-heavy keyspace. So you'll be ok as long as you don't plan on performing user maintenance during a node failure.

将system_auth的复制因子设置为其中的节点数群集应该可以。至少，我要说的是，您应该确保将其复制到所有数据中心。

Setting the replication factor of system_auth to the number of nodes in the cluster should be ok. At the very least, I would say you should make sure it replicates to all of your data centers.

如果您仍然想知道问题的这一部分，则： / p>

In case you were still wondering about this part of your question:

较旧的文档似乎建议它应该为N，其中n是节点数，而较新的文档则建议将其设置为a大于1的数字。

The older docs seem to suggest it should be N where n is the number of nodes, while the newer ones suggest we should set it to a number greater than 1."

我今天在2.1文档配置身份验证：

将system_auth密钥空间的复制因子增加到N
（节点数）。

Increase the replication factor for the system_auth keyspace to N (number of nodes).

只需确保

附录20181108

所以我最初在我有过的最大的集群受管有10个节点。四年后，在将其中三个管理大型（100+）节点集群的服务器投入大型零售商之后，我对此的看法有所改变。我可以说我不再同意四年前的这种说法。

So I originally answered this back when the largest cluster I had ever managed had 10 nodes. Four years later, after spending three of those managing large (100+) node clusters for a major retailer, my opinions on this have changed somewhat. I can say that I no longer agree with this statement of mine from four years ago.

这就是为什么我实际上要确保我的system_auth键空间复制到我的所有节点。

This is why I actually do ensure that my system_auth keyspace replicates to all of my nodes.

在大型（20-50个节点）集群上，我们已经部署了 system_auth 的RF高达8。只要您不移动节点，并且假定默认的cassandra / cassandra用户不再在游戏中就可以使用。

A few times on mind-to-large (20-50 nodes) clusters , we have deployed system_auth with RFs as high as 8. It works as long as you're not moving nodes around, and assumes that the default cassandra/cassandra user is no longer in-play.

在集群中存在弊端，集群的大小倾向于波动。当然，大小变化的集群通常会这样做，因为跨多个提供程序的吞吐量要求很高，这使事情变得更加复杂。我们注意到，有时应用程序团队会报告此类群集上的身份验证失败。通过在所有 system_auth 表上运行 SELECT COUNT（*），我们能够迅速纠正这种情况，从而强制执行阅读修复。但是，下一次我们添加/删除几个节点时，问题往往会再次浮出水面。

The drawbacks were seen on clusters which have a tendency to fluctuate in size. Of course, clusters which change in size usually do so because of high throughput requirements across multiple providers, further complicating things. We noticed that occasionally, the application teams would report auth failures on such clusters. We were able to quickly rectify these situation, by running a SELECT COUNT(*) on all system_auth tables, thus forcing a read repair. But the issue would tend to resurface the next time we added/removed several nodes.

由于较大集群的大小可能会发生波动，因此现在像对待其他任何键空间一样对待 system_auth 。也就是说，我们设置 system_auth 的RF到每个DC中的3。

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.

这似乎工作得很好。它解决了在高吞吐量，动态环境中管理太多副本所带来的问题。毕竟，如果RF = 3对于您的应用程序数据足够好，那么对于 system_auth 来说可能就足够了。

That seems to work really well. It gets you around the problems that come with having too many replicas to manage in a high-throughput, dynamic environment. After all, if RF=3 is good enough for your application's data, it's probably good enough for system_auth.

这篇关于用于system_auth的复制因子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！