An overview of new features in Cassandra.
Compaction and repair improvements:
- Post-compaction read performance
- A configurable percentage of cold SSTables can be ignored
- Incremental node repair
- Pre-Cassandra 2.0 SSTables are no longer supported in Cassandra 2.1 and later. To upgrade to Cassandra 2.1 from a previous release that stored Cassandra 1.2.x SSTables, see Cassandra versions requiring intermediate upgrades.
- The shuffle utility for migrating to virtual nodes (vnodes) and the nodetool taketoken command have been removed. To migrate to vnodes, bootstrap a new data center.
- Cassandra 2.1 bundles and enables JNA. If JNA fails to initialize, you can disable JNA by using the -Dcassandra.boot_without_jna=true option to start Cassandra.
- Incremental replacement of compacted SSTables has been disabled.
- Improved Hadoop support
- Unique table IDs
- Improved logging using logback
- New configuration options for allocating and managing memtable memory
- Improvements to bootstrapping a node that ensure data consistency
- A number of other CQL and cqlsh changes
- Configurable properties have been added to manage counter writes.
- A configurable counter cache reduces lock contention and helps with concurrency.
- CASSANDRA-6504 has been backported to Cassandra 2.0.5 so you can perform a rolling upgrade of a database having counters to Cassandra 2.1.
- Default data and log locations have changed for tarball installations and source checkouts. By default, the data file directory, commitlog directory, and saved caches directory are in $CASSANDRA_HOME/data/data, $CASSANDRA_HOME/data/commitlog, and $CASSANDRA_HOME/data/saved_caches, respectively. The log directory now defaults to $CASSANDRA_HOME/logs. If not set, $CASSANDRA_HOME, defaults to the top-level directory of the installation. Deb and RPM packages continue to use /var/lib/cassandra and /var/log/cassandra by default.
- Cassandra 2.1 maintains data consistency during bootstrapping. As you bootstrap a new node, Cassandra streams the data for the new node from an existing node that is free from range movement. If data inconsistency issues are present in the cluster, the improvement to bootstrapping handles these issues. Data inconsistency commonly occurs after frequent data deletions and a node going down.
To inhibit the new Cassandra 2.1 bootstrapping behavior, and make Cassandra 2.0 behavior effective, start the node using the -Dcassandra.consistent.rangemovement=false property:
- Package installations: Add the following option to
- Tarball installations: Start Cassandra with this
$ bin/cassandra -Dcassandra.consistent.rangemovement=false
To replace a dead node, you also need to specify the address of the node from which Cassandra streams the data.
- Package installations: Add the following option to /usr/share/cassandra/cassandra-env.sh file:
For a detailed list of changes, see the Cassandra 2.1 change log.