[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427226#comment-17427226
]
Stefan Miklosovic commented on CASSANDRA-14557:
-----------------------------------------------
Hi [~sumanth.pasupuleti]
There is a replication strategy called "EverywhereStrategy" we managed to
implement (1). If one uses that strategy, it will place data to all replicas in
the cluster without user specifying a thing. I dont want to go into details and
reasons and so on, but as I was reading your patch, I spotted this code (2).
So if I understand that properly, we are not expecting any options in our
strategy, so options are empty. But there you say that if options are empty,
lets put a replication factor into them. But we do not want this to happen,
because the "default rf" will be just wrong in our strategy.
However, even you are setting that rf on empty options, it does not seem to
collide with anything we have (3), I have tested that if I set default rf to be
2 and I have three nodes, when I use EverywhereStrategy, it will still
replicate data to 3 nodes instead of 2 so the behaviour seems to be preserved
and the introduction of that code does not violate anything.
I just want to highlight the fact that we are "injecting" some defaults here
which might have yet-unknown consequencies. Hence I would document this
behaviour by modifying NetworkTopologyStrategy.prepareOptions Javadoc telling
what exactly happens when options are empty so implementators of new
replication strategies can reflect this.
(1) [https://github.com/instaclustr/cassandra-everywhere-strategy#testing]
(2)
[https://github.com/apache/cassandra/blob/83a082be2ea396a44f8a5e7883bd9702b1e7d767/src/java/org/apache/cassandra/locator/NetworkTopologyStrategy.java#L269-L275]
(3)
[https://github.com/instaclustr/cassandra-everywhere-strategy/blob/master/cassandra-4/src/main/java/org/apache/cassandra/locator/EverywhereStrategy.java]
> Add default and required keyspace replication options
> -----------------------------------------------------
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Sumanth Pasupuleti
> Assignee: Sumanth Pasupuleti
> Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
