Apache Cassandra 1.0 Documentation

Upgrading Cassandra

This section includes information on upgrading Cassandra between releases:

Major Releases Minor Releases
Upgrading Cassandra: 0.8.x to 1.0.x Upgrading Between Minor Releases of Cassandra 1.0.x

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:

  1. On each node, download and unpack the 1.0 binary tarball package from the downloads section of the Cassandra website.
  2. 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.
  3. Make sure any client drivers – such as Hector or Pycassa clients – are 1.0-compatible.
  4. Run nodetool drain on the 0.8.x node to flush the commit log.
  5. Stop the old Cassandra process, then start the new binary process.
  6. Monitoring the log files for any issues.
  7. After upgrading and restarting all Cassandra processes, restart client applications.
  8. 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:

  1. On each of your Cassandra nodes, run sudo yum install apache-cassandra1.
  2. 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.
  3. Make sure any client drivers – such as Hector or Pycassa clients – are 1.0-compatible.
  4. Run nodetool drain on the 0.8.x node to flush the commit log.
  5. Restart the Cassandra process.
  6. Monitor the log files for any issues.
  7. After upgrading and restarting all Cassandra processes, restart client applications.
  8. 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:

  1. On each of your Cassandra nodes, run sudo apt-get install cassandra1.
  2. 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.
  3. Make sure any client drivers, such as Hector or Pycassa clients, are 1.0-compatible.
  4. Run nodetool drain on the 0.8.x node to flush the commit log.
  5. Restart the Cassandra process.
  6. Monitor the log files for any issues.
  7. After upgrading and restarting all Cassandra processes, restart client applications.
  8. 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:

  1. On each node, download and unpack the binary tarball package from the downloads section of the Cassandra website .
  2. 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.
  3. Make sure any client drivers, such as Hector or Pycassa clients, are compatible with the new version.
  4. Flush the commit log on the upgraded node by running nodetool drain.
  5. Stop the old Cassandra process, then start the new binary process.
  6. Monitor the log files for any issues.

To upgrade a Debian or RHEL package installation:

  1. On each node, download and install the package from the downloads section of the Cassandra website .
  2. 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.
  3. Make sure any client drivers, such as Hector or Pycassa clients, are compatible with the new version.
  4. Flush the commit log on the upgraded node by running nodetool drain.
  5. Restart the Cassandra process.
  6. Monitor the log files for any issues.
Powered by Rackspace
Apache, Apache Cassandra, Cassandra, Apache Hadoop, Hadoop and the eye logo are trademarks of the Apache Software Foundation.