DataStax Enterprise 2.1 Documentation

Completing the Configuration and Starting Up the Upgraded Node

A few configuration settings need to be made before the process of upgrading from DataStax Community 1.0.x to DataStax Enterprise 2.1.x is finished.

  1. Configure the snitch setting as described in Configuring the Snitch Setting.

  2. If you customized any property files other than the cassandra-topology.properties, update files by hand, similar to way you merged configuration file settings.

    Do not copy these property files from the prior release and overwrite files in the new release. Users who have attempted this have reported problems.

  3. Start the node.

    You can use a rolling restart as described in the next section. Monitor the log files for any issues.

  4. If necessary, upgrade any CQL drivers and client libraries, such as python-cql, Hector, or Pycassa that are incompatible with the new DSE version. You can download CQL drivers and client libraries from the DataStax download page.

    The CQL utility is included in the DataStax Enterprise installation, so no upgrade of the CQL utility is necessary.

  5. After upgrading and starting all nodes, restart client applications.

  6. Repeat the upgrade procedures on the next node in the cluster.

Using a Rolling Restart

Using a rolling restart, you upgrade and start one node at a time, instead of bringing down the entire cluster and starting all nodes at once. DataStax supports rolling restarts of nodes.

A rolling restart is not fully supported on Analytics nodes. Starting Analytics nodes using a rolling restart floods the log files with exceptions. The Hadoop job tracker repeatedly logs exceptions until all analytics nodes are upgraded. The runtime exception you see when starting analytics nodes looks something like this snippet.

INFO [pool-3-thread-1] 2012-03-22 02:09:08,868 Server.java (line 542)
IPC Server listener on 8012: readAndProcess threw exception
java.lang.RuntimeException: readObject can't find class. . .

You can ignore these exceptions. When the last node upgrades, restarts, and joins the cluster, the exceptions cease. If you can accept these exceptions being added to the log file, use the rolling restart. As previously mentioned, upgrade and start the new job tracker node first.

Validating the Upgrade

After all nodes are upgraded, validate the upgrade.

To validate the upgrade

  1. Using the Command Line Interface (CLI), run the DESCRIBE CLUSTER command:

    $ cassandra-cli -host localhost -port 9160

[default@unknown] DESCRIBE cluster;

    If any node is UNREACHABLE, you see output something like this:

    [default@unknown] describe cluster;
Cluster Information:
Snitch: com.datastax.bdp.snitch.DseDelegateSnitch
Partitioner: org.apache.cassandra.dht.RandomPartitioner
Schema versions:
UNREACHABLE: [10.202.205.203, 10.80.207.102, 10.116.138.23]

  2. Restart unreachable nodes.

  3. Repeat steps 1 and 2 until all nodes show the same schema number.