Upgrading DataStax Enterprise 3.0 to 3.2

Review this information and follow these instructions to upgrade from DataStax Enterprise 3.0.x to DataStax Enterprise 3.2.x.

DataStax is offering a complimentary half-day Upgrade Assessment. This assessment is a DataStax Services engagement designed to assess the upgrade compatibility of your existing DSE deployment to later DSE versions, including 5.1, 6.0, 6.7, and 6.8. Contact the DataStax Services team to schedule your assessment.*

Analytics nodes

While upgrading a cluster, some column families created through Hadoop interfaces might not appear to contain data. After the upgrade process has completed, the data is visible again.

DataStax Enterprise and Apache Cassandra® configuration files

DataStax Enterprise (DSE) configuration files
Configuration file Installer-Services and package installations Installer-No Services and tarball installations

dse

/etc/default/dse (systemd) or /etc/init.d/ (SystemV)

N/A Node type is set via command line flags.

dse-env.sh

/etc/dse/dse-env.sh

<installation_location>/bin/dse-env.sh

byoh-env.sh

/etc/dse/byoh-env.sh

<installation_location>/bin/byoh-env.sh

dse.yaml

/etc/dse/dse.yaml

<installation_location>/resources/dse/conf/dse.yaml

logback.xml

/etc/dse/cassandra/logback.xml

<installation_location>/resources/logback.xml

spark-env.sh

/etc/dse/spark/spark-env.sh

<installation_location>/resources/spark/conf/spark-env.sh

spark-defaults.conf

/etc/dse/spark/spark-defaults.conf

<installation_location>/resources/spark/conf/spark-defaults.conf

Cassandra configuration files

Configuration file

Installer-Services and package installations

Installer-No Services and tarball installations

cassandra.yaml

/etc/dse/cassandra/cassandra.yaml

<installation_location>/conf/cassandra.yaml

cassandra.in.sh

/usr/share/cassandra/cassandra.in.sh

<installation_location>/bin/cassandra.in.sh

cassandra-env.sh

/etc/dse/cassandra/cassandra-env.sh

<installation_location>/conf/cassandra-env.sh

cassandra-rackdc.properties

/etc/dse/cassandra/cassandra-rackdc.properties

<installation_location>/conf/cassandra-rackdc.properties

cassandra-topology.properties

/etc/dse/cassandra/cassandra-topology.properties

<installation_location>/conf/cassandra-topology.properties

jmxremote.password

/etc/cassandra/jmxremote.password

<installation_location>/conf/jmxremote.password

Tomcat server configuration file
Configuration file Installer-Services and package installations Installer-No Services and tarball installations

server.xml

/etc/dse/resources/tomcat/conf/server.xml

<installation_location>/resources/tomcat/conf/server.xml

Partitioner

Edit the cassandra.yaml file to change the partitioner setting to match the previous partitioner. The default RandomPartitioner (org.apache.cassandra.dht.RandomPartitioner) was the default partitioner prior to Apache Cassandra 1.2.

CQL 3

Do not issue any CQL 3 queries until all nodes are upgraded and schema disagreements are resolved.

Security recommendations

The client_encryption_options for enabling client-to-node SSL have been removed from dse.yaml starting in 3.1.2. To enable client-to-node SSL, set the option in the cassandra.yaml file.

Before upgrading from 3.0.x to 3.2.x, 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:

  • Kerberos

  • Object permission management (internal authorization)

  • Internal authentication

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 Apache Cassandra updates the security options. First merge the following settings into the new configuration files:

  • authenticator

  • authorizer

  • auth_replication_strategy

  • auth_replication_options

  • any other diffs

Use the old settings while you are upgrading the cluster so that backward compatibility is maintained. For example, the new file at this point contains the old Cassandra 1.1 authenticator and authorizer options:

  • authenticator: com.datastax.bdp.cassandra.auth.PasswordAuthenticator

  • authorizer: org.apache.cassandra.auth.CassandraAuthorizer

If you are upgrading a secure cluster, there could 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 might 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.

  1. 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
  2. Remove or comment out these options from the cassandra.yaml file:

    • auth_replication_strategy

    • auth_replication_options

    • replication_factor

    If you have not disabled both auth_replication_strategy and replication_factor, you will see an error. For information about correcting this error, see Issues in the DataStax Enterprise 3.2.5 release notes.

  1. Optional: 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.

Virtual nodes (vnodes)

DataStax recommends using vnodes only on datacenters running Cassandra workloads. To disable vnodes on datacenters that run Hadoop or Solr workloads, set num_tokens to 1 in cassandra.yaml.

Solr

If you make changes to the configuration of a Solr node after upgrading, you must set the type mapping correctly as explained in Configuring the Solr type mapping version.

Recommissioning a node

If you decommissioned a node in the last 72 hours:

  • Do not recommission the node until another 72 hours has passed.

  • If you wish to recommission the node after 72 hours, run nodetool gossipinfo. Check the STATUS line for the token of the decommissioned node and verify that it does not exist. If it does not exist, then the node has been deleted and it is safe to recommission the node.

  • If you need to bring the node into the cluster, contact Support regarding how to kill the node.

Was this helpful?

Give Feedback

How can we improve the documentation?

© 2024 DataStax | Privacy policy | Terms of use

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: +1 (650) 389-6000, info@datastax.com