Close popover

Table of Contents

Removing DDS nodes from a Cassandra cluster

Version:

Reduce the size of a Cassandra cluster by permanently removing Decision Data Store (DDS) nodes from the cluster. This procedure allows the cluster to rebalance itself and ensures that the removed nodes are not reintroduced into the cluster.

Before you remove any Cassandra directories or data directories from a node, ensure that you first remove the node from the Cassandra cluster and then make suitable backups of these assets before you take any non-reversible actions.
  1. Run the nodetool utility from any machine in the Cassandra cluster.

  2. Run a parallel repair on the node to repair and correctly replicate the data owned by the node:

    nodetool repair -par
  3. Remove the node:

    nodetool removenode <ID>

    where ID is the ID of the node that you want to remove. You can view the node ID by running the nodetool status command.

    You can also remove nodes from Pega Platform by using the Decommission action. For more information, see Managing decision management nodes.
    The data is streamed from the removed node to the nodes that now own or replicate the data. The removal is complete when the command prompt returns or the node is no longer listed when you run the nodetool status command.
  4. Perform a graceful shutdown of the Pega Java virtual machine (JVM).

  5. If there are other services than DDS on the node, and the node still needs to be part of the Pega cluster, remove the DDS entry from the NodeType setting on the node.

    If the original node type was set to -DNodeType=DDS, ADM, Web, then set the node type to -DNodeType=ADM, Web.

    In this example, the node is still responsible for the ADM and Web node types, and needs to be restarted.

  6. Restart the Pega JVM.

  7. Repair and clean up the remaining nodes:

    1. Run a parallel repair on each remaining node to ensure that any data that was not replicated for any reason during the removal is repaired and replicated correctly:

      nodetool repair -par
    2. Run a cleanup on each remaining node to remove any data that no longer belongs to the nodes:

      nodetool cleanup
Verify that the cluster is in a consistent state with all appropriate nodes reporting the correct ownership, and that the application performs correctly. For more information, see Nodetool commands for monitoring Cassandra clusters.

  • Assigning decision management node types to Pega Platform nodes

    Assign decision management node types to Pega Platform nodes to scale data ingestion or decision processing.

  • Repairing and cleaning Cassandra nodes for data consistency

    To guarantee data consistency and cluster-wide data health, run a Cassandra repair and cleanup regularly, even when all nodes in the services infrastructure are continuously available. Regular Cassandra repair operations are especially important when data is explicitly deleted or written with a TTL value.

  • Cassandra overview

    Apache Cassandra is the primary means of storage for all of the customer, historical, and analytical data that you use in decision management. The following sections provide an overview of the most important Cassandra features in terms of scalability, data distribution, consistency, and architecture.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.