Documentation:HTCC:Dep:UpgradingCassandraTo2x:8.5.2DRAFT

Upgrading Cassandra to 2.2

New installations of Web Services are being built based on Cassandra 2.2.

If you are using an older version of Cassandra, we recommend that you upgrade your Cassandra versions in several steps. For example 1.1 > 1.2 > 2.0 > 2.2. For more information about upgrading Cassandra, see http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgrdCassandra.html.

Stop Cassandra after saving pending changes

The procedure requires shutdown of the service during the upgrade. On each node, you must disallow new changes, save pending changes, take a snapshot to rollback changes if something goes wrong, and stop Cassandra.

The following bash script performs this functionality and may have to be adjusted to match your actual directory structure:

apache-cassandra-1.1.12/bin/nodetool disablegossip
apache-cassandra-1.1.12/bin/nodetool disablethrift
apache-cassandra-1.1.12/bin/nodetool flush
apache-cassandra-1.1.12/bin/nodetool compact
apache-cassandra-1.1.12/bin/nodetool snapshot
cassandrapid=$(ps -ef | grep Cassandra | grep Daemon | tr -s ' ' | cut -d' ' -f2)
kill $cassandrapid

Install Cassandra 2.2

If the Cassandra 2.2 has to reside in the same directory, rename the old directory. Install Cassandra 2.2 using your preferred installation method.

Update Cassandra 2.2 configuration files

• Change configuration files in the same manner as for the previous Cassandra installation. Minimum requirements, set listen addresses, seeds and initial token.
• See Cassandra for the reference, then set commit, data, saved_caches directories to point to the same locations as in the previous Cassandra version containing existing files with old data.
• Set partitioner as RandomPartitioner.
• Set auto_bootstrap to false so that Cassandra does not start any massive data manipulation on startup before we upgraded SSTables to new format.

Below are step-by-step instructions for each configuration file, assuming initial state of files as they are immediately after a Cassandra installation:

cassandra.yaml

• Set cluster_name. It must be the same name on all nodes
• Set initial_token according to the place in ring. Token values are the same as in the previous version.
• Set seeds to the list of host names of all nodes excluding the current node, example: -seeds: "node2, node3, node4, node5, node6" on node1
• Set listen_address and rpc_address to host name
• Set data_file_directories, commitlog_directory and saved_caches_directory to the same values as in the previous version.
• Change endpoint_snitch to PropertyFileSnitch
• Set partitioner to org.apache.cassandra.dht.RandomPartitioner
• Set auto_bootstrap parameter to false
• Set start_rpc to true

log4j-server.properties

Create folder for log files or reuse the folder from the previous version installation. Set log4j.appender.R.File according to that folder.

cassandra-topology.properties

Copy cassandra-topology.properties used for the previous version.

Start Cassandra 1.2 and upgrade SSTables to new format

On each node start Cassandra 2.2 and run the nodetool upgradesstables command.

Resolve possible inconsistencies between nodes

On each node, run the nodetool repair command That is all. Web Services will work with new Cassandra version from this point on.

Updating Cassandra 2.2 to multiple vnodes and Murmur partitioner

Important

The Cassandra data import tool json2sstable turned out to be incompatible with the astyanax Cassandra client used in Web Services. The procedure described in the document produces correct tables but Web Services fails to read some of the values due to format incompatibilities. Hence the procedure cannot be used in existing customer deployments.