[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427378#comment-17427378
]
Joey Lynch commented on CASSANDRA-14557:
----------------------------------------
In the case where a datacenter does not have at least 3 nodes, the keyspace
creation statement would warn you have insufficient replication but still allow
it. So any datacenters that do not have enough nodes will simply fail at higher
consistency levels (which they should as with fewer than 3 replicas, you can't
have any form of consistency under partitions). For example on latest trunk:
{noformat}
cqlsh> CREATE KEYSPACE test WITH replication = {'class':
'NetworkTopologyStrategy', 'replication_factor': 3};
Warnings :
Your replication factor 3 for keyspace test is higher than the number of nodes
1 for datacenter datacenter1
{noformat}
Then if you try to operate in that datacenter with strongly consistent local
ops it will (correctly imo) fail:
{noformat}
qlsh> DESCRIBE KEYSPACE test ;
CREATE KEYSPACE test WITH replication = {'class': 'NetworkTopologyStrategy',
'datacenter1': '3'} AND durable_writes = true;
cqlsh> CONSISTENCY LOCAL_QUORUM
Consistency level set to LOCAL_QUORUM.
cqlsh> CREATE TABLE test.test (key text, value text, primary key (key));
cqlsh> INSERT INTO test.test (key, value) values ('hello', 'world');
NoHostAvailable: ('Unable to complete the operation against any hosts', {<Host:
127.0.0.1:9042 datacenter1>: Unavailable('Error from server: code=1000
[Unavailable exception] message="Cannot achieve consistency level LOCAL_QUORUM"
info={\'consistency\': \'LOCAL_QUORUM\', \'required_replicas\': 2,
\'alive_replicas\': 1}')})
cqlsh> CONSISTENCY LOCAL_ONE
Consistency level set to LOCAL_ONE.
cqlsh> INSERT INTO test.test (key, value) values ('hello', 'world');
{noformat}
The {{LOCAL_ONE}} still worked because we had at least one replica.
> 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: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
