JBoss Community Archive (Read Only)


Running a Single Node


Cassandra is designed to support running multiple nodes in a cluster. It is entirely possible to deploy only a single node (though many of Cassandra's features cannot be utilized). More over RHQ fully supports deploying a single storage node. This document covers configuration and maintenance of a single node deployment.

The information on this page is specific to a single node deployment.

Read Repair

Read repair should be run as a regularly scheduled maintenance operation to ensure data is consistent across replicas (i.e., nodes that own a particular range of keys) in the cluster. With a only single node, there is no need to run read repair. 


gc_grace_seconds is a table attribute that specifies the time to wait before garbage collecting tombstones (i.e., deletions). This allows for consistency to be achieved prior to deletion. For a single node cluster, gc_grace_seconds can be set to zero for each table.


Replication is one of the key features of Cassandra. There is no replication with a single node cluster; therefore, taking snapshots should be performed as a regularly occurring maintenance operation. It is very important to run regular backups on the system_auth keyspace. See the following section for more information on the system_auth keyspace.


RHQ uses Cassandra's internal authentication and authorization. Usernames, passwords, and permissions are stored in the system_auth keyspace. If the data for the system_auth keyspace was corrupted in some way, such as residing on a failing disk, it is likely that clients (i.e., the RHQ server) would not be able to log in. It is therefore imperative to keep backups of the system_auth keyspsace. 

JBoss.org Content Archive (Read Only), exported from JBoss Community Documentation Editor at 2020-03-11 12:57:26 UTC, last content change 2013-05-02 03:29:08 UTC.