In my last blog post ‘Setup a Public Cassandra Cluster with Docker‘ I described how to setup a Cassandra Cluster with docker in a public network. The important part of this blog post was how to secure the inter-node and client-node communication in such a scenario. In this bog post I will just cover some details about migrating from version 3.11 to version 4.0.
General Upgrade from 3.x to 4.0
In general it is quite simple to upgrade a Cassandra Node form version 3.x to 4.0 because the version 4.0 can handle the table files from version 3. So at least you need to change your Docker run command pointing to a 4.0 version:
docker run --name cassandra -d \ -e CASSANDRA_BROADCAST_ADDRESS=<YOUR-PUBLIC-IP> \ -e CASSANDRA_SEEDS=<COMMA SEPARATED IP LIST OF EXISTING NODES> \ -p 7000:7000 \ -p 9042:9042 \ -v ~/cassandra.yaml:/etc/cassandra/cassandra.yaml\ -v ~/cqlshrc:/root/.cassandra/cqlshrc\ -v ~/security:/security\ -v /var/lib/cassandra:/var/lib/cassandra\ --restart always\ cassandra:4.0.6
The cassandra.yaml File
Before you can start the new Cassandara node, you need to update the cassandra.yaml file.
First I recommand to start a local cassandra docker container and copy the origin
cassandra.yaml file from the running container. This is necessary because a lot of parameters and settings have change form version 3.x to 4.0
Now you can tweak the
cassandra.yaml file. In parallel you can check your current cluster configuration from a running node with docker:
docker exec -it cassandra cat /etc/cassandra/cassandra.yaml
First take care about the following parameters which should be set to your previous configuration settings:
- listen_address (usually out comment)
If you use the
server_encryption_options as explained in my last post you need take care about the following sections:
... server_encryption_options: #internode_encryption: none internode_encryption: all enable_legacy_ssl_storage_port: true keystore: /security/cassandra.keystore keystore_password: mypassword truststore: /security/cassandra.truststore truststore_password: mypassword # enable or disable client/server encryption. client_encryption_options: enabled: true optional: false keystore: /security/cassandra.keystore keystore_password: mypassword require_client_auth: false .... # enable password authentication! authenticator: PasswordAuthenticator ...
The important change is in the new parameter ‘
enable_legacy_ssl_storage_port‘ which need to be set to ‘true’ during migration.
Expose Port 7000
Since version 4.0 the port 7001 is deprecated. This port was used in older version for the encrypted inter-node communication. Now port 7000 is handling both – encypted as also unencrypted communication. So it is sufficient to expose port 7000 now for inter-node communication.
But as long as your cluster contains nods running with version 3.11 you need to set the new parameter ‘
enable_legacy_ssl_storage_port‘ to ‘true’. This parameter tells your 4.0 node to use still port 7001 when connecting to older nodes.
# When set to true, encrypted and unencrypted connections are allowed on the storage_port # This should _only be true_ while in unencrypted or transitional operation # optional defaults to true if internode_encryption is none # optional: true # If enabled, will open up an encrypted listening socket on ssl_storage_port. Should only be used # during upgrade to 4.0; otherwise, set to false. enable_legacy_ssl_storage_port: true
Note: The parameter ‘
‘ is only needed as long as your cluster has nodes running in version 3.x. Later you ignore this param. Which is typically only during the migration phase.
If you have completed the settings you can start the node again in version 4.0.6.
Java – DataStax Driver
If you have a Java client using the DataStax Java Driver to connect to your Cassandra Cluster make sure hat you use the latest Driver verson:
<!-- DataStax Java Driver --> <dependency> <groupId>com.datastax.cassandra</groupId> <artifactId>cassandra-driver-core</artifactId> <!-- for cassandra 4.0 use 3.11.3 or later --> <version>3.11.3</version> <scope>compile</scope> </dependency>
If you are running a firewall as explained in my last post you need take care about the new port settings. Port 7001 should no longer be needed.