[Cassandra Wiki] Update of Operations by JonathanElli s
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Operations page has been changed by JonathanEllis. http://wiki.apache.org/cassandra/Operations?action=diffrev1=54rev2=55 -- Important things to note: - 1. You should wait long enough for all the nodes in your cluster to become aware of the bootstrapping node via gossip before starting another bootstrap. For most clusters 30s will be plenty of time. + 1. You should wait long enough for all the nodes in your cluster to become aware of the bootstrapping node via gossip before starting another bootstrap. The new node will log Bootstrapping when this is safe, 2 minutes after starting. (90s to make sure it has accurate load information, and 30s waiting for other nodes to start sending it inserts happening in its to-be-assumed part of the token ring.) 1. Relating to point 1, one can only boostrap N nodes at a time with automatic token picking, where N is the size of the existing cluster. If you need to more than double the size of your cluster, you have to wait for the first N nodes to finish until your cluster is size 2N before bootstrapping more nodes. So if your current cluster is 5 nodes and you want add 7 nodes, bootstrap 5 and let those finish before boostrapping the last two. 1. As a safety measure, Cassandra does not automatically remove data from nodes that lose part of their Token Range to a newly added node. Run `nodetool cleanup` on the source node(s) (neighboring nodes that shared the same subrange) when you are satisfied the new node is up and working. If you do not do this the old data will still be counted against the load on that node and future bootstrap attempts at choosing a location will be thrown off. 1. When bootstrapping a new node, existing nodes have to divide the key space before beginning replication. This can take awhile, so be patient.
[Cassandra Wiki] Update of Committers by BrandonWilli ams
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The Committers page has been changed by BrandonWilliams. http://wiki.apache.org/cassandra/Committers?action=diffrev1=3rev2=4 -- ||Johan Oskarsson||Nov 2009||Twitter||Also a [[http://hadoop.apache.org/|Hadoop]] committer|| ||Gary Dusbabek||Dec 2009||Rackspace|| || ||Jaakko Laine||Dec 2009||?|| || + ||Brandon Williams||Jun 2010||Riptano|| ||
[jira] Updated: (CASSANDRA-1235) BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped
[ https://issues.apache.org/jira/browse/CASSANDRA-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Nine updated CASSANDRA-1235: - Attachment: TestEncodedKeys.java This file demonstrates the broken input. Notice that the first test passes with clean input. The second one fails utilizing batch write for the same input keys. BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped - Key: CASSANDRA-1235 URL: https://issues.apache.org/jira/browse/CASSANDRA-1235 Project: Cassandra Issue Type: Bug Affects Versions: 0.6.2 Environment: Java 1.6 sun JDK Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, Ubuntu 10.04 64 bit Reporter: Todd Nine Priority: Blocker Attachments: TestEncodedKeys.java When running the two tests, individual column insert works with the values generated. However, batch insert with the same values causes an encoding failure on the key. It appears bytes are dropped from the end of the byte array that represents the key value. See the attached unit test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (CASSANDRA-1235) BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped
BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped - Key: CASSANDRA-1235 URL: https://issues.apache.org/jira/browse/CASSANDRA-1235 Project: Cassandra Issue Type: Bug Affects Versions: 0.6.2 Environment: Java 1.6 sun JDK Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, Ubuntu 10.04 64 bit Reporter: Todd Nine Priority: Blocker When running the two tests, individual column insert works with the values generated. However, batch insert with the same values causes an encoding failure on the key. It appears bytes are dropped from the end of the byte array that represents the key value. See the attached unit test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-1235) BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped
[ https://issues.apache.org/jira/browse/CASSANDRA-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-1235: -- Fix Version/s: 0.6.4 Affects Version/s: 0.6 (was: 0.6.2) Priority: Critical (was: Blocker) BytesType and batch mutate causes encoded bytes of non-printable characters to be dropped - Key: CASSANDRA-1235 URL: https://issues.apache.org/jira/browse/CASSANDRA-1235 Project: Cassandra Issue Type: Bug Affects Versions: 0.6 Environment: Java 1.6 sun JDK Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, Ubuntu 10.04 64 bit Reporter: Todd Nine Priority: Critical Fix For: 0.6.4 Attachments: TestEncodedKeys.java When running the two tests, individual column insert works with the values generated. However, batch insert with the same values causes an encoding failure on the key. It appears bytes are dropped from the end of the byte array that represents the key value. See the attached unit test -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
