[ 
https://issues.apache.org/jira/browse/CASSANDRA-5953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13763064#comment-13763064
 ] 

Jeremiah Jordan commented on CASSANDRA-5953:
--------------------------------------------

Agreed.  I have seen this mis-feature used to good effect when things were 
going terribly wrong.  A bunch of nodes decommissioned/removed such that only 
two nodes were left in the ring, but reads and writes still worked fine, even 
though RF was 3.

If we do want to validate this I would suggest the only validation is done at 
CREATE time.  And not alter/insert time.
                
> Replication validation is broken
> --------------------------------
>
>                 Key: CASSANDRA-5953
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5953
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>            Priority: Minor
>             Fix For: 1.2.10
>
>
> On my local, single node cluster, RF=3 inserts should not succeed:
> {noformat}
> cqlsh> CREATE KEYSPACE mykeyspace WITH REPLICATION = { 'class' : 
> 'SimpleStrategy', 'replication_factor' : 3 };
> cqlsh> use mykeyspace ;
> cqlsh:mykeyspace> CREATE TABLE users (
>               ...   user_id int PRIMARY KEY, 
>               ...   fname text, 
>               ...   lname text
>               ... );
> cqlsh:mykeyspace> INSERT INTO users (user_id,  fname, lname) 
>               ...   VALUES (1745, 'john', 'smith');
> cqlsh:mykeyspace> select * from users;
>  user_id | fname | lname
> ---------+-------+-------
>     1745 |  john | smith
> {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to