Cassandra Best Practices

When you create a Cassandra client, the software creates a default subclient that contains all the data centers and Simple Strategy keyspaces.

Use the following guidelines when you want to manage Cassandra subclients:

• A data center or Simple Strategy keyspace can only be in one subclient.

• Have separate subclients for each data center so that you can take advantage of the storage targets (MediaAgents) that are close to the data center so that you can have better network performance.

• If you have a subclient that contains both the data centers, then the backup does not include the Simple Strategy keyspaces. Create a separate subclient for the Simple Strategy keyspaces.

• When you create a subclient for keyspaces that have the Simple Strategy replication factor, use a Geo MediaAgent, LAN-free or GridStor configuration for the storage. for more information, see GridStor®.

• To make sure that your data centers are regularly backed up, create a subclient for each data center, and then schedule a backup. For information on configuring a backup schedule, see Schedule Backups.

• Leave the default subclient intact so that it can be a catch-all for the following data:

  • Data center that are not part of any other subclient

  • Keyspaces that have the Simple Strategy replication factor and are not part of any other subclient

  • New auto-discovered data centers and Simple Strategy keyspaces

Keyspace Additions to Existing Clusters

When you add keyspaces that have the Simple Strategy replication factor to an existing Cassandra cluster, then the following rules apply to backups:

• If you have a user-defined subclient that contains Simple Strategy keyspaces, then the you need to add the keyspace to the subclient (Subclient Properties dialog box, Cassandra Contents tab). For more information, see Adding Simple Strategy Keyspaces to a Cassandra Subclient.

• If you do not have a user-defined subclient for the Simple Strategy keyspaces, then the keyspaces are added to the default subclient.

When you add a keyspace that has the network topology replication factor to an existing cluster, the Commvault software automatically adds the keyspace to the subclient that contains the data center that the keyspace is associated with.

Materialized View Creation During Restores

When you have Materialized views for a keyspace and the restore operation is slow, you can defer the creation of the Materialized View using the nDeferMateriazliedViewCreation additional setting.

The additional setting is used in the following scenarios:

If you drop or delete the keyspace and the Materialized View, run a full database recovery. The restore operation will recover the keyspace and then creates the Materialized View.

If you truncate the keyspace, and drop the Materialized View, run a database or keyspace recovery. After the restore operation completes, you must manually create the Materialized View.

Geolocation MediaAgents

If you have a Cassandra configuration that has datacenters or nodes in different network locations, then you can configure the Commvault software to use the MediaAgent that is geographically closest to the datacenter or node. For more information, see Using a Geolocation Based MediaAgent for Cassandra Protection.

Network Routes

If the Cassandra nodes are behind a firewall, configure the network topology on your CommCell as follows:

1. Create a client group and add the Cassandra coordinator node to the client group.

2. Create another client group and add all the remaining Cassandra nodes to the client group.

3. Open port 8403 on all the nodes.

4. On the coordinator client group, add a firewall rule stating blocked to the Cassandra client group.

5. On the Cassandra client group, add a firewall rule stating restricted to the Cassandra coordinator client group.

6. Push the network configurations on each client group (right-click the client group, point to All Tasks, and then click Push Network Configuration).