[
https://issues.apache.org/jira/browse/CASSANDRA-12629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15566292#comment-15566292
]
Ben Bromhead commented on CASSANDRA-12629:
------------------------------------------
This is not super important to get it committed as like you mentioned
replication strategies are pluggable, just keen to figure out what we are
missing here.
We are still not hugely comfortable with the default rf of the system_auth
keyspace and the way in which authN/Z information is replicated as the current
default is also pretty easy to shoot yourself in the foot (from what we have
seen helping folks out). Also while maintaining a separate process to manage
system_auth keyspace RF and repairs works... it is also somewhat unwieldy (this
is our current approach).
After doing some reading, particularly of
https://issues.apache.org/jira/browse/CASSANDRA-826, my gut feel is that
replication of authN/Z keyspace requires a more elegant solution than what an
"Everywhere" strategy would provide and should be more in line with the way the
schema keyspaces behave? Such a discussion may require a new ticket or there is
an existing one for it?
> All Nodes Replication Strategy
> ------------------------------
>
> Key: CASSANDRA-12629
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12629
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Alwyn Davis
> Priority: Minor
> Attachments: 12629-trunk.patch
>
>
> When adding a new DC, keyspaces must be manually updated to replicate to the
> new DC. This is problematic for system_auth, as it cannot achieve LOCAL_ONE
> consistency (for a non-cassandra user), until its replication options have
> been updated on an existing node.
> Ideally, system_auth could be set to an "All Nodes strategy" that will
> replicate it to all nodes, as they join the cluster. It also removes the
> need to update the replication factor for system_auth when adding nodes to
> the cluster to keep with the recommendation of RF=number of nodes (at least
> for small clusters).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
