Apache Cassandra 1.0 Documentation

Upgrading Cassandra

This document corresponds to an earlier product version. Make sure you are using the version that corresponds to your version.

Latest Cassandra documentation | Earlier Cassandra documentation

This section describes how to upgrade Cassandra 0.8.x to 1.0.x and how to upgrade between minor releases of Cassandra 1.0.x. The procedures also apply to DataStax Community Edition.

Best Practices for Upgrading Cassandra

The following steps are recommended before upgrading Cassandra:

  • Take a snapshot before the 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.

    Taking a snapshot is fast, especially if you have JNA installed, and takes effectively zero disk space until you start compacting the live data files again.

  • 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. Save the cassandra.yaml file from the old installation to a safe place.
  2. On each node, download and unpack the 1.0 binary tarball package from the downloads section of the Cassandra website.
  3. In the new installation, open the cassandra.yaml for writing.
  4. In the old installation, open the cassandra.yaml.
  5. Diff the new and old cassandra.yaml files.
  6. Merge the diffs by hand from the old file into the new one.
  7. Follow steps for completing the upgrade.

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. The installer creates the file cassandra.yaml.rpmnew in /etc/cassandra/default.conf/.
  2. Open the old and new cassandra.yaml files and diff them.
  3. Merge the diffs by hand from the old file into the new one. Save the file as cassandra.yaml.
  4. Follow steps for completing the upgrade.

To upgrade a Debian/Ubuntu packaged release installation from 0.8.x to 1.0.x:

  1. Save the cassandra.yaml file from the old installation to a safe place.
  2. On each of your Cassandra nodes, run sudo apt-get install cassandra1.
  3. Open the old and new cassandra.yaml files and diff them.
  4. Merge the diffs by hand from the old file into the new one.
  5. Follow steps for completing the upgrade.

Completing the Upgrade

To complete the upgrade, perform the following steps:

  1. Account for New and Changed Parameters between 0.8 and 1.0 in cassandra.yaml.
  2. Make sure any client drivers, such as Hector or Pycassa clients, are compatible with the new version.
  3. Run nodetool drain on the node to flush the commit log.
  4. Stop the old Cassandra process, then start the new binary process.
  5. Monitor the log files for any issues.
  6. After upgrading and restarting all Cassandra processes, restart client applications.
  7. After upgrading, run nodetool upgradesstables against each node before running repair, moving nodes, or adding new ones. If you are using Cassandra 1.0.3 and earlier, use nodetool scrub instead of nodetool upgradesstables.

Upgrading Between Minor Releases of Cassandra 1.0.x

The upgrade procedure between minor releases of Cassandra 1.1.x is identical to the upgrade procedure between major releases with one exception: Do not perform the last step of Completing the Upgrade to run nodetool upgradesstables or nodetool scrub after upgrading.

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 about 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