[ 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