|
|
| (15 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | = Upgrading Cassandra 1.2 to 2.X= | + | = 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. |
| | | | |
| − | {{#ponycomment:KrisMcG|This entire procedure is a copy of the 1.2 procedures. Masha and I will need to go through the steps and make current for 2.x.
| + | 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 {{#Widget:ExtLink|link=http://docs.datastax.com/en/upgrade/doc/upgrade/cassandra/upgdCassandra.html|displaytext=Datastax documentation}}. |
| − | |JIRA}} | |
| | | | |
| − | New installations of Web Services are being built based on Cassandra 1.2.
| + | #Stop all Web Services nodes. |
| | + | #Perform Cassandra upgrade according to the Datastax. |
| | + | #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 following upgrade procedure was tested on randomly generated data set on a cluster of 6 Ubuntu nodes in Amazon cloud. The records written in Cassandra version 1.1 were successfully read in Cassandra version 1.2 after upgrades done in accordance with the following procedure. The procedure was successfully tested with a staged Web Services deployment.
| + | [[Category:V:HTCC:8.5.2]][[Category:V:HTCC:8.5.2DRAFT]] |
| − | | |
| − | The only change in Web Services deployment is setting Cassandra version to 1.2 in the <tt>cassandra-cluster.yaml</tt> file.
| |
| − | __TOC__
| |
| − | | |
| − | ==Stop Cassandra 1.1 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:
| |
| − | | |
| − | <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 1.2==
| |
| − | If the Cassandra 1.1 has to reside in the same directory rename the old directory. Install Cassandra 1.2 using your preferred installation method. (In the mentioned tests Cassandra was just unzipped/untarred to a separate directory alongside the existing 1.1 installation. The renaming was not required.)
| |
| − | | |
| − | ==Update Cassandra 1.2 configuration files==
| |
| − | *Change configuration files in the same manner as for Cassandra 1.1 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 Cassandra 1.1 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 version 1.1
| |
| − | *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 version 1.1
| |
| − | *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 false
| |
| − | | |
| − | ===log4j-server.properties===
| |
| − | Create folder for log files or reuse the folder from version 1.1 installation. Set <tt>log4j.appender.R.File</tt> according to that folder.
| |
| − | | |
| − | ===cassandra-topology.properties===
| |
| − | Copy <tt>cassandra-topology.properties</tt> used for version 1.1
| |
| − | | |
| − | ==Start Cassandra 1.2 and upgrade SSTables to new format==
| |
| − | On each node start Cassandra 1.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 1.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]] | |
