Upgrading Cassandra
This section includes information on upgrading Cassandra between releases:
Note
This information also applies to DataStax Community Edition.
Best Practices for Upgrading Cassandra
The following best practices are recommended when upgrading Cassandra:
Always take a snapshot before any upgrade. This allows you to rollback to the previous version if necessary. Cassandra is able to read data files created by the previous version, but the inverse is not always true.
Note
Snapshotting is fast, especially if you have JNA installed, and takes effectively zero disk space until you start compacting the live data files again.
Be sure to check https://github.com/apache/cassandra/blob/trunk/NEWS.txt for any new information on upgrading.
For a list of fixes and new features, see https://github.com/apache/cassandra/blob/trunk/CHANGES.txt
Upgrading Cassandra: 0.8.x to 1.0.x
Upgrading from version 0.8 or later can be done with a rolling restart, one node at a time. You do not need to bring down the whole cluster at once.
To upgrade a binary installation from 0.8.x to 1.0.x:
- On each node, download and unpack the 1.0 binary tarball package from the downloads section of the Cassandra website.
- Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml. You can copy your existing 0.8.x configuration file into the upgraded Cassandra instance and manually update it with new content.
- Make sure any client drivers – such as Hector or Pycassa clients – are 1.0-compatible.
- Run nodetool drain on the 0.8.x node to flush the commit log.
- Stop the old Cassandra process, then start the new binary process.
- Monitoring the log files for any issues.
- After upgrading and restarting all Cassandra processes, restart client applications.
- After upgrading, run nodetool upgradesstables against each node before running repair, moving nodes, or adding new ones. (If using Cassandra 1.0.3 and earlier, use nodetool scrub instead.)
To upgrade a CentOS/RHEL packaged release installation from 0.8.x to 1.0.x:
- On each of your Cassandra nodes, run sudo yum install apache-cassandra1.
- Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml. The installer creates the file cassandra.yaml.rpmnew in /etc/cassandra/default.conf/. You can diff this file with your existing configuration and add new content.
- Make sure any client drivers – such as Hector or Pycassa clients – are 1.0-compatible.
- Run nodetool drain on the 0.8.x node to flush the commit log.
- Restart the Cassandra process.
- Monitor the log files for any issues.
- After upgrading and restarting all Cassandra processes, restart client applications.
- After upgrading, run nodetool upgradesstables against each node before running repair, moving nodes, or adding new ones. (If using Cassandra 1.0.3 and earlier, use nodetool scrub instead.)
To upgrade a Debian/Ubuntu packaged release installation from 0.8.x to 1.0.x:
- On each of your Cassandra nodes, run sudo apt-get install cassandra1.
- Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml. The installer creates the file cassandra.yaml.rpmnew in /etc/cassandra/default.conf/. You can diff this file with your existing configuration and add new content.
- Make sure any client drivers, such as Hector or Pycassa clients, are 1.0-compatible.
- Run nodetool drain on the 0.8.x node to flush the commit log.
- Restart the Cassandra process.
- Monitor the log files for any issues.
- After upgrading and restarting all Cassandra processes, restart client applications.
- After upgrading, run nodetool upgradesstables against each node before running repair, moving nodes, or adding new ones. (If using Cassandra 1.0.3 and earlier, use nodetool scrub instead.)
New and Changed Parameters between 0.8 and 1.0
This table lists cassandra.yaml parameters that have changed between 0.8 and 1.0. See the cassandra.yaml reference for details on these parameters.
| Option |
Default Value |
| 1.0 Release |
| broadcast_address |
Same as listen_address - set to the public IP in multi-region EC2 clusters |
| compaction_thread_priority |
Removed (use compaction_throughput_mb_per_sec instead) |
| commitlog_rotation_threshold_in_mb |
Removed |
| commitlog_total_space_in_mb |
4096 (replaces column family storage property memtable_flush_after_mins) |
| multithreaded_compaction |
false |
| memtable_total_space_in_mb |
1/3 of heap (replaces column family storage properties
memtable_operations_in_millions and memtable_throughput_in_mb) |
| 0.8 Release |
| seed_provider |
SimpleSeedProvider |
| seeds |
Now a comma-delimited list in double quotes. |
| memtable_total_space_in_mb |
1/3 of heap |
| compaction_throughput_mb_per_sec |
16 |
| concurrent_compactors |
One per CPU |
| internode_encryption |
none |
| keystore |
conf/.keystore |
| keystore_password |
cassandra |
| truststore |
conf/.truststore |
| truststore_password |
cassandra |
Upgrading Between Minor Releases of Cassandra 1.0.x
Upgrading minor releases can be done with a rolling restart, one node at a time. You do not need to bring down the whole cluster at once.
To upgrade a binary tarball package installation:
- On each node, download and unpack the binary tarball package from the downloads section of the Cassandra website .
- Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml. You can copy your existing configuration file into the upgraded Cassandra instance and manually update it with new content.
- Make sure any client drivers, such as Hector or Pycassa clients, are compatible with the new version.
- Flush the commit log on the upgraded node by running nodetool drain.
- Stop the old Cassandra process, then start the new binary process.
- Monitor the log files for any issues.
To upgrade a Debian or RHEL package installation:
- On each node, download and install the package from the downloads section of the Cassandra website .
- Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml. You can copy your existing configuration file into the upgraded Cassandra instance and manually update it with new content.
- Make sure any client drivers, such as Hector or Pycassa clients, are compatible with the new version.
- Flush the commit log on the upgraded node by running nodetool drain.
- Restart the Cassandra process.
- Monitor the log files for any issues.