Jump to: navigation, search
(Upgrading Cassandra to 2.2)
(Upgrading Cassandra to 2.2)
Line 1: Line 1:
 
= Upgrading Cassandra to 2.2=
 
= Upgrading Cassandra to 2.2=
  
New installations of Web Services are being built based on Cassandra 2.2.
+
Web Services support Cassandra versions 2.2 and 1.2. If you are using Cassandra 1.2, you can maintain this version or upgrade to 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.
+
Directly upgrading from 1.2 to 2.2 is not supported, therefore you need to upgrade your Cassandra versions in several steps. For example 1.2 > 2.0 > 2.1 > 2.2. For more information about upgrading Cassandra, see the [http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgdCassandra.html Datastax documentation].
  
==Stop Cassandra after saving pending changes==
+
#Stop all Web Services nodes.
 +
#;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.
 +
#Perform Cassandra upgrade according to the [http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgrdBestPractCassandra.html Datastax recommendations].
 +
#When configuring Cassandra 2.2 according to the Datastax instructions,  you must enable the thrift interface. Set the the '''start_rpc''' parameter to <tt>true</tt> in the '''cassandra.yaml''' file
 +
#Start all Web Services nodes.
  
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:
 
 
<pre>
 
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
 
</pre>
 
 
==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 <tt>listen addresses</tt>, seeds and initial token.
 
*See Cassandra for the reference, then set <tt>commit</tt>, <tt>data</tt>, <tt>saved_caches</tt> directories to point to the same locations as in the previous Cassandra version containing existing files with old data.
 
*Set <tt>partitioner</tt> as <tt>RandomPartitioner</tt>.
 
*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 <tt>cluster_name</tt>. It must be the same name on all nodes
 
*Set <tt>initial_token</tt> 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: <tt>-seeds: "node2, node3, node4, node5, node6" on node1</tt>
 
*Set <tt>listen_address</tt> and <tt>rpc_address</tt> to host name
 
*Set <tt>data_file_directories</tt>, <tt>commitlog_directory</tt> and <tt>saved_caches_directory</tt> to the same values as in the previous version.
 
*Change <tt>endpoint_snitch</tt> to <tt>PropertyFileSnitch</tt>
 
*Set partitioner to <tt>org.apache.cassandra.dht.RandomPartitioner</tt>
 
*Set <tt>auto_bootstrap</tt> parameter to <tt>false</tt>
 
*Set <tt>start_rpc</tt> to <tt>true</tt>
 
 
===log4j-server.properties===
 
Create folder for log files or reuse the folder from the previous version installation. Set <tt>log4j.appender.R.File</tt> according to that folder.
 
 
===cassandra-topology.properties===
 
Copy <tt>cassandra-topology.properties</tt> 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 <tt>nodetool upgradesstables</tt> command.
 
 
==Resolve possible inconsistencies between nodes==
 
On each node, run the <tt>nodetool repair</tt> 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==
 
 
{{NoteFormat|The Cassandra data import tool <tt>json2sstable</tt> turned out to be incompatible with the <tt>astyanax</tt> 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.}}
 
 
[[Category:V:HTCC:8.5.2]]
 
[[Category:V:HTCC:8.5.2]]

Revision as of 14:20, August 24, 2016

Upgrading Cassandra to 2.2

Web Services support Cassandra versions 2.2 and 1.2. If you are using Cassandra 1.2, you can maintain this version or upgrade to Cassandra 2.2.

Directly upgrading from 1.2 to 2.2 is not supported, therefore you need to upgrade your Cassandra versions in several steps. For example 1.2 > 2.0 > 2.1 > 2.2. For more information about upgrading Cassandra, see the Datastax documentation.

  1. Stop all Web Services nodes.
    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.
  2. Perform Cassandra upgrade according to the Datastax recommendations.
  3. When configuring Cassandra 2.2 according to the Datastax instructions, you must enable the thrift interface. Set the the start_rpc parameter to true in the cassandra.yaml file
  4. Start all Web Services nodes.
Comments or questions about this documentation? Contact us for support!