Upgrading directly from versions other than these does not work:
To upgrade from earlier versions, first upgrade to DataStax Enterprise 2.2, and then upgrade the SSTables.
To upgrade from a Brisk release, contact Support.
Merge your partitioner setting from the old to the new file. Do not attempt to use the Cassandra 1.2 default partitioner option, Murmur3Partitioner, in the new file unless you were already using it.
Do not issue any CQL 3 queries until all nodes are upgraded and schema disagreements are resolved.
The client_encryption_options for enabling client-to-node SSL have been removed from dse.yaml in 3.1.2 and later. To enable client-to-node SSL, set the option in the cassandra.yaml file.
Before upgrading, if you use these DataStax Enterprise security features, adjust the replication strategy and options in the cassandra.yaml file to configure a replication factor for the dse_auth keyspace greater than 1:
Adjust the replication factor for dse_auth on each node in the cluster. After updating the cassandra.yaml file and restarting the node, run nodetool repair to repair the first range returned by the partitioner for the keyspace:
nodetool repair dse_auth -pr
This should only take a few seconds to complete.
The new version of Cassandra updates the security options. First simply merge the following settings into the new configuration files:
Use the old settings while you are upgrading the cluster so that backward compatibility is maintained. For example, the new file contains the old, Cassandra 1.1 authenticator and authorizer options at this point:
If you are upgrading a secure cluster, there may be a significant delay to each node's first startup as the security migration takes place (up to 1 minute). The delay is due to ensuring that the ring is fully connected before the migration starts. During the upgrade of a secure cluster, you may see a security related error message (documented below). You will see the following message in the log when the node has completed the migration:
INFO [NonPeriodicTasks:1] 2013-06-22 15:01:08,173 Auth.java (line 208) Migration of legacy auth data is complete. You should now switch to org.apache.cassandra.auth implementations in cassandra.yaml.
After all nodes have been upgraded, change these options to the new Cassandra 1.2 values and perform a rolling restart as explained below.
If using Kerberos authentication, there are no credentials data to migrate, but user records must still be updated. Merge the related diffs from the old to the new file.
Edit the cassandra.yaml to switch to the official Apache versions of PasswordAuthenticator and CassandraAuthorizer:
authenticator: org.apache.cassandra.auth.PasswordAuthenticator authorizer: org.apache.cassandra.auth.CassandraAuthorizer
Remove these options from the cassandra.yaml file:
Optionally, adjust the replication factor of the system_auth keyspace. The amount of data in this keyspace is typically very small, so leaving it replicated across the cluster is relatively cheap.
After restarting each node, consider upgrading sstables. Upgrading SSTables is highly recommended under these conditions:
Upgrade SSTables before doing these operations:
Because these operations copy SSTables within the cluster and the on-disk format sometimes changes between major versions, DataStax recommends upgrading SSTables now to prevent possible future SSTable incompatibilities:
DataStax recommends using virtual nodes only on data centers running purely Cassandra workloads. You should disable virtual nodes on data centers running either Hadoop or Solr workloads by setting num_tokens to 1 in the cassandra.yaml.
If you are upgrading a Solr node, make the default legacy type mapping effective by commenting out the dseTypeMappingVersion element:
<!-- <dseTypeMappingVersion>1</dseTypeMappingVersion> -->
If you are upgrading from DataStax Enterprise 3.0.x, an exception that looks something like this might appear in logs during a rolling upgrade. Ignore these error messages:
ERROR 15:36:54,908 Exception in thread Thread[GossipStage:1,5,main] java.lang.NumberFormatException: For input string: "127605887595351923798765477786913079296" . . .
When upgrading Cassandra 1.2 nodes, you can ignore the following error messages related to when a node is attempting to push mutations to the new system_auth keyspace:
ERROR [WRITE-/192.168.123.11] 2013-06-22 14:13:42,336 OutboundTcpConnection.java (line 222) error writing to /192.168.123.11 java.lang.RuntimeException: Can't serialize ColumnFamily ID 2d324e48-3275-3517-8dd5-9a2c5b0856c5 to be used by version 5, because int <-> uuid mapping could not be established (CF was created in mixed version cluster). at org.apache.cassandra.db.ColumnFamilySerializer.cfIdSerializedSize(ColumnFamilySerializer.java:196)
When upgrading a Solr node, you can ignore the following error:
ERROR 00:57:17,785 Cannot activate core: ks.cf_10000_keys_50_cols ERROR 00:57:17,786 <indexDefaults> and <mainIndex> configuration sections are discontinued. Use <indexConfig> instead. ERROR 01:29:55,145 checksum mismatch in segments file (resource: ChecksumIndexInput(MMapIndexInput(path="/var/lib/cassandra/data/solr.data/ks. cf_10000_keys_50_cols/index/segments_6"))) ERROR 01:29:55,145 Solr index ks.cf_10000_keys_50_cols seems to be corrupted: please CREATE the core again with recovery=true to start reindexing data. ERROR 01:29:55,145 Cannot activate core: ks.cf_10000_keys_50_cols ERROR 01:29:55,146 checksum mismatch in segments file (resource: ChecksumIndexInput (MMapIndexInput(path="/var/lib/cassandra/data/solr.data/ks. cf_10000_keys_50_cols/index/segments_6"))) org.apache.lucene.index.CorruptIndexException: checksum mismatch in segments file (resource: ChecksumIndexInput(MMapIndexInput ( path="/var/lib/cassandra/data/solr.data/ks.cf_10000_keys_50_cols/index/segments_6")))
If you decommissioned a node in the last 72 hours: