cassandra.yaml configuration file

The cassandra.yaml file is the main configuration file for Hyper-Converged Database (HCD).

After changing properties in the cassandra.yaml file, you must restart the node for the changes to take effect (with a few exceptions).

Syntax

For the properties in each section, the parent setting has zero spaces. Each child entry requires at least two spaces. Adhere to the YAML syntax and retain the spacing.

Default values that are not defined are shown as Default: none.

Internally defined default values are described.

HCD can define default values internally, comment them out, or create implementation dependencies on other properties in the cassandra.yaml file. Additionally, some commented-out values may not match the actual default values. DataStax recommends the commented out values as alternatives to the default values.

Quick start properties

These are the minimal properties needed for configuring a cluster:

cluster_name

The name of the cluster. This setting prevents nodes in one logical cluster from joining another so it is important to set it to a unique name other than the default. All nodes in a cluster must have the same value.

Default: 'Test Cluster'

rpc_address

The address that client applications connect to. You typically set this to a node’s public IP address that is routable from the clients.

If not changed from the default localhost, only applications deployed on the server will be able to connect to the node.

Default: localhost

listen_address

The IP address or hostname that the database binds to, exclusively for private communication between nodes in the cluster. This is typically set to a node’s private IP that is routable from other nodes.

If not changed from the default localhost, the node will not be able to communicate with other nodes in the cluster.

Never set listen_address to 0.0.0.0.

Set listen_address or listen_interface but not both.

The recommended usage of listen_address or listen_interface depend on your deployment architecture:

Architecture Option 1 Option 2

Single-node installation

Use the default setting of localhost.

If the node is properly configured with the host name, name resolution, and other necessary information, then the database uses InetAddress.getLocalHost() to get the local address from the system automatically.

Comment out listen_address.

If the node is properly configured with the host name, name resolution, and other necessary information, then the database uses InetAddress.getLocalHost() to get the local address from the system automatically.

A node in a multi-node installation

Set listen_address to the node’s IP address or hostname.

Set listen_interface.

A node in a multi-network or multi-datacenter installation, deployed on EC2, and supports automatic switching between public and private interfaces:

Set listen_address to the node’s IP address or hostname.

Set listen_interface.

A node with two physical network interfaces in a multi-datacenter installation

or

A cluster deployed across multiple EC2 regions using the Ec2MultiRegionSnitch

  1. Set listen_address to the node’s private IP or hostname for communication within the local datacenter.

  2. Set broadcast_address to the second IP or hostname for communication between datacenters.

  3. Set listen_on_broadcast_address to true.

  4. If the node is a seed node, add the node’s public IP address or hostname to the seeds list in cassandra.yaml.

  1. Set listen_interface for communication within the local datacenter.

  2. Set broadcast_address to the second IP or hostname for communication between datacenters.

  3. Set listen_on_broadcast_address to true.

  4. If the node is a seed node, add the node’s public IP address or hostname to the seeds list in cassandra.yaml.

Also, make sure the storage_port or ssl_storage_port is open on the public IP firewall.

Default: localhost

listen_interface

The interface that the database binds to for connecting to other nodes. Interfaces must correspond to a single address. HCD does not support IP aliasing.

Never set listen_address to 0.0.0.0.

Set listen_address or listen_interface but not both.

For use cases, see listen_address.

listen_interface_prefer_ipv6

Use IPv4 or IPv6 when an interface is specified by name.

  • false: Use first IPv4 address.

  • true: Use first IPv6 address.

When you use only a single address, HCD selects that address without regard to this setting.

listen_interface_prefer_ipv6

Use IPv4 or IPv6 when an interface is specified by name:

  • false (default): Use first IPv4 address.

  • true: Use first IPv6 address.

When you use only a single address, HCD selects that address without regard to this setting.

Default directories

If you have changed any of the default directories during installation, set these properties to the new locations. Make sure you have root access.

data_file_directories

The directory where table data is stored on disk. The database distributes data evenly across the location, subject to the granularity of the configured compaction strategy.

For production, DataStax recommends RAID-0 and SSDs. For more information, see Capacity planning and hardware selection for HCD deployments.

Default: /var/lib/cassandra/data

commitlog_directory

The directory where HCD stores the commit log.

For optimal write performance, place the commit log on a separate disk partition, or ideally on a separate physical device, from the data directories. Because the commit log only appends data, a hard disk drive (HDD) works as long as it keeps up with the writes.

Default: $CASSANDRA_HOME/data/commitlog

The commitlog_directory and the cdc_raw_directory must reside on the same partition. Keep these directories in separate sub-folders that are not nested.

cdc_raw_directory

The directory where HCD stores change data capture (CDC) commit log segments on flush when cdc_enabled: true. DataStax recommends using a physical device that is separate from the data directories. See Change Data Capture (CDC) logging.

Default: $CASSANDRA_HOME/data/cdc_raw

The cdc_raw_directory and the commitlog_directory must reside on the same partition. Keep these directories in separate sub-folders that are not nested.

hints_directory

The directory where HCD stores hints (missed writes).

Default: $CASSANDRA_HOME/data/hints

metadata_directory

The directory that holds cluster metadata including information about the local node and its peers.

Default: $CASSANDRA_HOME/data/metadata

saved_caches_directory

The directory location where HCD stores saved counter and row cache keys if enabled.

Default: $CASSANDRA_HOME/data/saved_caches

Data directory configuration

Distributing data across multiple disks, also known as Just a Bunch Of Disks (JBOD) configuration, can improve throughput and efficiency of disk I/O. HCD lets you specify multiple directories for storing your data in this distributed manner.

DataStax recommends using striped LVM instead of JBOD for disk management. For more information, see RAID on data disks.

To configure a single JBOD data directory in the cassandra.yaml file:

data_file_directories:
     - /var/lib/cassandra/data

For multiple JBOD data directories:

data_file_directories:
     - /disk1/datadir
     - /disk2/datadir
     - /disk3/datadir

Commonly used properties

These are the properties most frequently used when configuring HCD.

Before starting a node for the first time, DataStax recommends that you carefully evaluate your requirements.

Common initialization properties

Be sure to set the properties in the Quick start section as well.

commit_failure_policy

Determines how HCD handles commit log disk failures.

  • die: Shut down the node and kill the JVM, so the node can be replaced.

  • stop: Shut down the node, leaving the node effectively dead, available for inspection using JMX.

  • stop_commit: Shut down the commit log, letting writes collect but continuing to service reads.

  • ignore: Ignore fatal errors and let the batches fail.

Default: stop (recommended)

disk_optimization_strategy

Reading from spinning disks is slow so HCD buffers them with an extra page of 4KB just in case. This is unnecessary for SSDs so HCD buffers only what is required.

  • ssd: Data directory backed by solid state disks

  • spinning: Data directory backed by spinning disks

Default: ssd

disk_failure_policy

Determines how HCD handles disk failures.

  • die: Shut down gossip and client transports, and kill the JVM for any file system errors or single SSTable errors, so the node can be replaced.

  • stop_paranoid: Shut down the node, even for single SSTable errors.

  • stop: Shut down the node leaving the node effectively dead, but the JVM is still available for inspection using JMX.

  • best_effort: Stop using the failed disk and respond to requests based on the remaining available SSTables. This setting allows obsolete data at consistency level of ONE.

  • ignore: Ignore fatal errors and let the requests fail; all file system errors are logged but otherwise ignored.

Recommended policies are stop and best_effort. Default: stop

endpoint_snitch

Configure this property to set the snitch. The most common snitches are:

  • Default: SimpleSnitch + Uses replication strategy order for proximity. This snitch does not recognize racks or datacenters, and considers all nodes as belonging to one ring (single DC) making it incompatible with multi-DC deployments and unsuitable for production environments. + This snitch is appropriate for development environments only.

  • GossipingPropertyFileSnitch (GPFS)

    Uses rack and datacenter information for the local node defined in the `cassandra-rackdc.properties` file and propagates this information to other nodes via gossip.
    This snitch is recommended for production environments and is almost always the correct choice.
  • PropertyFileSnitch (PFS)
    Determines node proximity using the rack and datacenter location defined in the cassandra-topology.properties file. GPFS supersedes this snitch. Configure this property to set the snitch.

    The most common snitches are:

    • SimpleSnitch (default): Uses replication strategy order for proximity. This snitch does not recognize racks or datacenters, and considers all nodes as belonging to one ring (single DC) making it incompatible with multi-DC deployments and unsuitable for production environments.

      This snitch is appropriate for development environments only.

    • GossipingPropertyFileSnitch (GPFS): Uses rack and datacenter information for the local node defined in the cassandra-rackdc.properties file and propagates this information to other nodes via gossip.

      This snitch is recommended for production environments and is almost always the correct choice.

    • PropertyFileSnitch (PFS): Determines node proximity using the rack and datacenter location defined in the cassandra-topology.properties file.

      GPFS is recommended over PFS. Only use PFS for backwards compatibility.

    For other supported snitches, including Ec2Snitch, Ec2MultiRegionSnitch, RackInferringSnitch, GoogleCloudSnitch, AlibabaCloudSnitch, AzureSnitch, and CloudStackSnitch, see About snitches.

    All nodes in a cluster must use the same snitch.

    HCD determines replica placement (which defines where copies of data are stored) using the information provided by the snitch. Changing the snitch has implications for where the data is located so requires additional steps and should only be performed by experienced operators.

seed_provider

The gossip seed provider and corresponding addresses of nodes that are designated as contact points in the cluster. A joining node contacts the nodes in the seeds list and establishes a connection to the first available node to discover the members of the cluster and topology.

  • class_name: The class that handles the seed logic. The default is appropriate for most clusters. For specific edge cases, you can substitute a custom seed provider class. + Default: org.apache.cassandra.locator.SimpleSeedProvider

  • seeds: A comma delimited list of addresses and their corresponding storage_port. A new node joining the cluster uses the list to bootstrap the gossip process. If the cluster has multiple nodes, the default value must be changed to the IP address and gossip port of one of the nodes.

  • parameters.resolve_multiple_ip_addresses_per_dns_record: When a DNS name in seeds resolves to multiple IP addresses, controls whether all resolved addresses are used (true) or only the first one (false).

    Default: "127.0.0.1:7000" for seeds; false for resolve_multiple_ip_addresses_per_dns_record

    Making every node a seed node is not recommended because of increased maintenance and reduced gossip performance. Gossip optimization is not critical, but it is recommended to use a small seed list of approximately three nodes per datacenter.

Advanced initialization properties

allocate_tokens_for_keyspace (not recommended)

The token allocation algorithm for vnodes distributes token ranges across nodes in a datacenter based on the number of nodes and the value of num_tokens. With allocate_tokens_for_keyspace, token distribution also considers a specified replication factor, resulting in a more balanced distribution compared to legacy random allocation (without vnodes).

Requires the following:

  • num_tokens must be set.

  • partitioner must be set to the Murmur3Partitioner class.

  • initial_token must be commented out or not set.

  • allocate_tokens_for_local_replication_factor must be commented out or not set.

Set allocate_tokens_for_keyspace to the name of an existing keyspace with defined replication properties. The keyspace’s replication factor, such as 3, is used for token allocation.

allocate_tokens_for_local_replication_factor is recommended over allocate_tokens_for_keyspace because it doesn’t require a preexisting keyspace.

Default: Not set (fallback to allocate_tokens_for_local_replication_factor or, if neither allocate_tokens_* parameters are set, use legacy random allocation)

allocate_tokens_for_local_replication_factor (recommended)

The token allocation algorithm for vnodes distributes token ranges across nodes in a datacenter based on the number of nodes and the value of num_tokens. With allocate_tokens_for_local_replication_factor, token distribution also considers a specified replication factor, resulting in a more balanced distribution compared to legacy random allocation (without vnodes).

Requires the following:

  • num_tokens must be set.

  • partitioner must be set to the Murmur3Partitioner class.

  • initial_token must be commented out or not set.

  • allocate_tokens_for_keyspace must be commented out or not set.

Set allocate_tokens_for_local_replication_factor to the keyspace replication factor in the node’s local datacenter, such as 3.

allocate_tokens_for_local_replication_factor is recommended over allocate_tokens_for_keyspace because it doesn’t require a preexisting keyspace.

Default: Not set (fallback to allocate_tokens_for_keyspace)

auto_bootstrap

When joining a cluster for the first time, this property determines whether the node will request replicas to stream data. This is the default behavior. If the node is defined as a seed node, it immediately joins the cluster without data.

Non-seed nodes will bootstrap automatically by default. Set to false when adding nodes in a new datacenter where bootstrap is manually triggered by an operator with the nodetool rebuild command.

Default: true

broadcast_address

Set to the node’s public IP address in environments where nodes are only able to communicate across networks using their public IP addresses such as multi-region Amazon EC2 deployments. Otherwise, the node will broadcast on the same address as listen_address.

Set a separate listen_address and broadcast_address on a node with multiple network interfaces or where nodes are not able to communicate over private IP addresses. Not required in environments that support automatic switching between private and public communication.

Default: uses value of listen_address

initial_token

Manually assign tokens for token range allocation to nodes:

  • Single-token architecture: Specify one token value per node.

  • Virtual nodes (vnodes): Specify multiple tokens as a comma-separated list. However, num_tokens is preferred over initial_token for simplified, automated token allocation.

    Default: Not set (fallback to num_tokens)

listen_on_broadcast_address

Set to true on nodes with multiple interfaces to enable communication on both listen_address and broadcast_address.

Default: false

num_tokens

When using vnodes, defines the number of token ranges to assign to the node:

  • 1: Monolithic and inflexible when scaling.

  • 2 to 8: Compared to 16 tokens, these values result in greater node availability (faster internode communication) but more variance in data size per node. 4 or 8 tokens can be more performant for large clusters.

  • 16 (default): Provides high elasticity for scaling and distributes data without significant reduction in availability for all but the largest clusters.

  • More than 16 tokens: Rarely necessary but can be used.

If num_tokens is set:

  • DataStax recommends that you also set allocate_tokens_for_local_replication_factor.

  • initial_token must be commented out or not set.

  • partitioner must be set to the Murmur3Partitioner class.

partitioner

The partitioner determines how data is distributed across the nodes in the cluster.

The default Murmur3Partitioner is the correct and only choice for new clusters. The legacy partitioners are provided for backward-compatibility with existing clusters upgraded from earlier versions of Cassandra since the partitioner can never be changed on a running cluster.

Default: org.apache.cassandra.dht.Murmur3Partitioner

Common compaction settings

compaction_throughput

The rate at which HCD compacts SSTable candidates, expressed as throughput. For example, 64MiB/s. The faster the database inserts data, the faster HCD must compact in order to keep the number of SSTables down.

Set to 16 to 32 times the write throughput. Otherwise, set to 0 to disable compaction throttling. A high setting means that HCD uses more disk I/O for compaction, leaving less I/O bandwidth for reads.

Default: 64MiB/s

Memtable settings

When a node receives a write request, HCD stores the data in a memory structure called a memtable and appends it to the commit log on disk for durability (see How data is written). HCD can allocate memtable segments either on- or off-heap.

memtable_allocation_type

Determines how HCD allocates memory to the memtable.

  • heap_buffers: HCD allocates memtables on JVM heap. Suitable for general workloads where heap memory is sufficient.

  • offheap_buffers: Uses Java NIO direct buffers to store cell names and values off-heap. This allocation type reduces heap utilization significantly, leading to reduced GC pressure.

  • offheap_objects: Allocates memtables completely off-heap, directly in native memory. This allocation type is recommended particularly for clusters that handle large datasets. Writes are around 5% faster mostly due to memtables flushing less often.

Default: offheap_objects

memtable

Selects the memtable implementation and configures named memtable profiles. The default profile is applied to any table that does not specify a memtable property.

Two implementations are available:

  • SkipListMemtable: Legacy memtable implementation used in earlier versions.

  • TrieMemtable: Uses a trie data structure to move more metadata off-heap, reduce garbage collection pressure, and handle higher write throughput. Because it is a sharded single-writer solution, it may perform worse when the load is very unevenly distributed. For example, when most writes access a very small number of partitions, or with legacy secondary indexes.

memtable:
  configurations:
    skiplist:
      class_name: SkipListMemtable
    trie:
      class_name: TrieMemtable
    default:
      inherits: trie

Default: trie

memtable_heap_space

The maximum amount of memory to allocate for memtables on JVM heap, expressed as a size. For example, 2048MiB. When the threshold is reached, writes are blocked until a flush completes.

Default: ¼ of heap

memtable_offheap_space

The maximum amount of memory to allocate for memtables from native memory, expressed as a size. For example, 2048MiB. When the threshold is reached, writes are blocked until a flush completes.

Default: ¼ of heap

memtable_cleanup_threshold

The threshold that triggers a flush based on the ratio of memtable size to the maximum memory size permitted for memtables.

Deprecated and commented out by default because the default calculation is the only reasonable choice. Only uncomment for backwards compatibility when upgrading. For more information, see the comments on this parameter in your installation’s default cassandra.yaml file.

Default: 1 / (memtable_flush_writers + 1)

memtable_flush_writers

The total number of memtables that can be flushed concurrently as well as the number of flush writer threads per disk. Factors into the memtable flush threshold calculation.

Commented out and uses the default value of 2 for nodes with a single data directory. For nodes with multiple data directories, the default behavior is 1 memtable flushed at a time (sequential individual memtable flushes).

Typically, there is no need to tune this parameter, and increasing this value can degrade performance. To determine if memtable flushes are falling behind, check if the MemtablePool.BlockedOnAllocation metric is greater than 0. If this metric is too large, then you might need to adjust this parameter.

For more information, see the comments on this parameter in your installation’s default cassandra.yaml file.

Common automatic backup settings

Backups and snapshots are not automatically cleared, which can cause unbounded increases in disk usage. By default, when the disk is full, HCD automatically shuts down because it can no longer write files to disk.

DataStax recommends setting up a process to clear incremental backups each time a new snapshot is created.

auto_snapshot

When enabled (set to true), a snapshot is taken before DROP KEYSPACE, DROP TABLE, or TRUNCATE TABLE is executed.

DataStax strongly recommends keeping this enabled as a precaution in case a DROP or TRUNCATE command is executed accidentally against the wrong keyspace or table.

Default: true

auto_snapshot_ttl

Time-to-live for automatically created snapshots, expressed as a duration. For example, 30d. Snapshots older than this are automatically deleted. Set to 0 to disable automatic deletion of snapshots.

Default: 0 (snapshots are not automatically deleted)

snapshot_links_per_second

Throttle for the number of hard links created or removed per second when creating or clearing snapshots. A non-zero value limits the rate to avoid performance impact, particularly on consumer SSDs.

Default: 0 (no throttle)

incremental_backups

When enabled (set to true), HCD creates hard links to each SSTable that has been flushed or streamed in the backups/ subdirectory of the keyspace data. You can also enable incremental backups for an individual table using the incremental_backups table property.

Default: false

snapshot_before_compaction

When enabled (set to true), a snapshot is taken before each compaction task. The snapshot may be used as a rollback position in an upgrade. Usage is limited since the general recommendation is to take backups before performing an upgrade.

Use with extreme caution as disk usage can grow exponentially.

Default: false

Performance tuning

Tuning performance and system resource utilization, including commit log, compaction, memory, disk I/O, CPU, reads, and writes.

See also Memtable settings.

Hinted handoff settings

When a node is temporarily unavailable, other nodes hold hints — short records of missed mutations — and replay them when the node recovers. For more information, see Hinted handoff repair.

hinted_handoff_enabled

Whether hinted handoff is enabled globally. When false, no hints are generated for any unavailable replica.

Default: true

hinted_handoff_disabled_datacenters

A list of datacenters for which hinted handoff is disabled when hinted_handoff_enabled is true. All other datacenters continue to receive hints. Because hinted_handoff_enabled defaults to true, all datacenters receive hints unless explicitly listed here.

hinted_handoff_disabled_datacenters:
  - DC1
  - DC2

Default: Empty (hinted handoff enabled for all datacenters)

max_hint_window

The maximum amount of time hints are generated for a dead node, expressed as a duration.For example, 3h. After this window, new hints for the node are not created until the node has been seen alive again and goes down again.

Default: 3h

hinted_handoff_throttle

Maximum throttle for hint delivery, expressed as throughput. For example, 1024KiB/s. The rate is reduced proportionally to the number of nodes in the cluster.

Default: 1024KiB/s

max_hints_delivery_threads

Number of threads used to deliver hints. Consider increasing this value for multi-datacenter deployments where cross-datacenter handoff tends to be slower.

Default: 2

hints_flush_period

How often hints are flushed from internal buffers to disk, expressed as a duration. This does not trigger an fsync.

Default: 10000ms (10 seconds)

max_hints_file_size

Maximum size of a single hints file, expressed as a size. For example, 128MiB.

Default: 128MiB

max_hints_size_per_host

Maximum total size of hints stored per target host, expressed as a size. Older hints are deleted to stay within this limit.

Default: Not set (no per-host limit)

auto_hints_cleanup_enabled

Whether to automatically delete hints for nodes that have been removed from the cluster.

Default: false

transfer_hints_on_decommission

When true, a decommissioning node transfers its pending hints to other nodes before leaving the cluster.

Default: true

hint_window_persistent_enabled

When true, the hint window state (how long a node has been down) is persisted across node restarts so that the hint window does not reset when the hinting node is restarted.

Default: true

Commit log settings

commitlog_sync

Defines the mode by which the commit log is synchronized to disk. When the data is considered fully persisted to storage, the data will survive a system crash or power outage. The sync mode also determines when HCD sends a successful write acknowledgement to the coordinator.

  • batch: Each write request triggers a call to sync immediately. The acknowledgement is blocked until the after the commit log has been flushed to disk. Prioritizes durability over performance.

  • group: Similar to batch mode but waits up to commitlog_sync_group_window between flushes so more writes are persisted together. HCD also blocks the acknowledgement until after the commit log has been flushed to disk. Recommended over batch mode.

  • periodic: HCD synchronizes the commit log every commitlog_sync_period but the write is acknowledged immediately. Prioritizes performance over durability.

Default: periodic

commitlog_sync_period

Time interval between commit log syncs to disk, expressed as a duration. For example, 10000ms. Only set with periodic sync mode, otherwise an exception will be logged.

Default: 10000ms (10 seconds)

periodic_commitlog_sync_lag_block

The number of milliseconds to block writes while waiting for a slow disk flush to complete in periodic sync mode.

Default: Not set (no blocking)

commitlog_sync_group_window

The duration between disk syncs. Only set with group sync mode, otherwise an exception will be logged.

Default: 1000ms (1 second)

commitlog_segment_size_in_mb

The size of individual commit log file segments. A small size means more frequent flushes leading to small SSTables which put pressure on compaction.

If you use the commit log archives for point-in-time recovery, it is reasonable to reduce the size to 16MiB or 8MiB for finer granularity. For more information, see max_mutation_size.

Default: 32MiB

commitlog_disk_access_mode

Sets the disk access mode for writing commit log segments:

  • auto: Version-dependent optimal setting. Default when storage_compatibility_mode isn’t CASSANDRA_4.

  • legacy: Default when storage_compatibility_mode is CASSANDRA_4. Uses standard for a compressed or encrypted commit log, and uses mmap for uncompressed and unencrypted commit logs.

  • mmap: Memory-mapped I/O. Available only when the commit log is uncompressed and unencrypted.

  • direct: Direct I/O. Available only when the commit log is uncompressed and unencrypted.

  • standard: Standard I/O. Available only when the commit log is compressed or encrypted.

flush_compression

The compression algorithm applied to SSTable data blocks when flushing a compressed table to disk. High-ratio compressors such as LZ4HC, Zstd, and Deflate can block flushes for too long, so the default uses a faster compressor for flush.

Available options:

  • fast (default): Flush with a fast compressor. If the table already uses a fast compressor, that compressor is used.

  • none: Flush without compressing blocks, but still writes checksums.

  • table: Always flush with the same compressor as the table (pre-4.0 behavior).

max_mutation_size

The maximum allowed size of a mutation (the payload size of a write request), expressed as a size. For example, 16MiB. Defaults to half the size of commitlog_segment_size. If explicitly set, you must set commitlog_segment_size to at least twice the value of max_mutation_size.

Before increasing the commit log segment size, investigate why the mutations are larger than expected. Look for underlying issues with access patterns and data model, because increasing the segment size is a limited fix.

Default: ½ of commitlog_segment_size

commitlog_total_space

The maximum disk space for commit logs on disk, expressed as a size. For example, 8192MiB.

If the limit is reached, the oldest commit log segments are flushed to reclaim disk space. A small size means more frequent flushes on less-active tables leading to small SSTables which put pressure on compaction.

Default: smaller of 8192MiB or ¼ of /commitlog disk

commitlog_compression

By default, the commit log is not compressed. To enable compression, specify the compression library to use.

The supported libraries are:

  • DeflateCompressor: Not recommended. Legacy option that is the slowest compared to newer algorithms.

  • LZ4Compressor: Fastest algorithm but offers less compression ratios. Choose when speed is preferred over space savings.

  • SnappyCompressor: Not as fast as LZ4 but provides better compression.

  • ZstdCompressor: Provides the best compression ratio but slower than other algorithms.

    commitlog_compression:
      - class_name: LZ4Compressor
    By default, the commit log is not compressed.
    +
    To enable compression, specify the compression library to use.
    For example:
    +
    [source,yaml]

    commitlog_compression:

    • class_name: LZ4Compressor

+
The supported libraries are:
+
* `DeflateCompressor`: Not recommended.
Legacy option that is the slowest compared to newer algorithms.
* `LZ4Compressor`: Fastest algorithm but offers less compression ratios.
Choose when speed is preferred over space savings.
* `SnappyCompressor`: Not as fast as LZ4 but provides better compression.
* `ZstdCompressor`: Provides the best compression ratio but slower than other algorithms.

[#hints_compression]
`hints_compression`::
The compressor for hint files.
When not set, the database does not compress hints files.
+
To enable compression, specify the compressor class name.
The supported compressors are:
+
--
* `LZ4Compressor`: Fastest algorithm, but offers lower compression ratios.
* `SnappyCompressor`: Not as fast as LZ4, but provides higher compression ratios.
* `DeflateCompressor`: Not recommended.
Legacy option that is the slowest compared to newer algorithms.
--
+
Default: Compression disabled
+
[source,yaml]

hints_compression: - class_name: LZ4Compressor parameters: - lz4_compressor_type: fast By default, the hints file isn’t compressed.

+ To enable hint file compression, specify the compressor to use by class name. For example:

+

hints_compression:
 - class_name: LZ4Compressor
   parameters:
    - lz4_compressor_type: fast

+ The supported compressors are:

+ * LZ4Compressor: Fastest algorithm, but offers lower compression ratios. * SnappyCompressor: Not as fast as LZ4, but provides higher compression ratios. * DeflateCompressor: Not recommended. Legacy option that is the slowest compared to newer algorithms.

Change Data Capture (CDC) settings

cdc_enabled

Enables CDC functionality on a per-node basis when set to true.

Default: false

cdc_block_writes

When cdc_enabled is true and the CDC raw directory is full, determines whether write requests to CDC-enabled tables are blocked (true) or silently dropped (false).

Default: true

cdc_on_repair_enabled

When true, repairs propagate CDC mutations to the CDC raw directory on the repaired node.

Default: true

cdc_total_space

Maximum disk space to use for CDC logs, expressed as a size. For example, 4096MiB. If the limit is reached, HCD throws WriteTimeoutException on mutations, including CDC-enabled tables. A CDCCompactor (a consumer) parses the raw CDC logs and deletes them when parsing is completed.

Default: smaller of 4096MiB or 1/8th of cdc_raw_directory disk

cdc_free_space_check_interval

Interval between disk space checks when the cdc_total_space limit is reached, expressed as a duration. For example, 250ms.

Default: 250ms

Concurrency settings

concurrent_reads

The number of concurrent read threads. For workloads with more data than fits in memory, set to this value to 16 times the number of drives. This ensures the the OS and drives have enough queue depth to reorder requests efficiently.

Default: 32

concurrent_writes

The number of concurrent write threads. Writes are rarely I/O bound, so the ideal value is 8 times the number of CPU cores.

Default: 32

concurrent_counter_writes

The number of concurrent counter write threads. Counter writes read the current value before incrementing, so they behave similarly to reads. Set to the same value as concurrent_reads.

Default: 32

concurrent_materialized_view_writes

The number of concurrent materialized view write threads. Because materialized view writes include a read step, this value should be limited to the lesser of concurrent_reads or concurrent_writes.

Default: 32

Compaction settings

For more information about compaction strategies and settings, see Configure compaction.

concurrent_compactors

The number of compaction threads allowed to run simultaneously. Simultaneous compactions help preserve read performance in a mixed read-write workload by limiting the number of small SSTables that accumulate during a single long-running compaction.

Generally, the calculated default value is appropriate and does not need adjusting. DataStax recommends contacting IBM Support before changing this value. If your data directories are backed by solid-state drives (SSDs), increase this value to the number of cores.

If compaction runs too slowly or too fast, adjust the compaction_throughput option.

Increasing concurrent compactors leads to more use of available disk space for compaction, because concurrent compactions happen in parallel, especially for STCS. Ensure that adequate disk space is available before increasing this configuration.

Default: 8

concurrent_validations

The number of repair validation threads allowed to run simultaneously.

Uses the value of concurrent_compactors if not set or set to a negative number.

To exceed concurrent_compactors, you must set the system property -Dcassandra.allow_unlimited_concurrent_validations to true.

Default: concurrent_compactors

concurrent_materialized_view_builders

The number of view builder tasks allowed to run simultaneously if materialized views are enabled. This is experimental.

When a view is created, the node ranges are split into [num_processors x 4] builder tasks. Set this property to 2 or higher to build views faster.

Default: 1

default_compaction

The default compaction strategy and properties to use when a table doesn’t explicitly set compaction properties. Also applies to system tables.

default_compaction:
  class_name: UnifiedCompactionStrategy
  parameters:
    scaling_parameters: T4
    max_sstables_to_compact: 64
    target_sstable_size: 1GiB
    sstable_growth: 0.3333333333333333
    min_sstable_size: 100MiB

Default: UnifiedCompactionStrategy with the default values for UCS.

sstable

Selects the SSTable format for new SSTables using the selected_format subproperty:

  • bti (default, recommended): Trie-indexed format that offers better read performance than big.

  • big: The legacy SSTable format. Use this for migrations from DSE, Cassandra 3.x, or 4.x where big SSTables are already in use.

sstable:
  selected_format: bti

The default value for selected_format shown here is bti. If your cassandra.yaml file shows a different value or an empty comment, the actual default is still bti as the format used by new installations.

sstable_preemptive_open_interval

The size threshold at which the compaction process opens new SSTables before they are fully written, expressed as a size. For example, 50MiB. Set to null to disable preemptive opening.

The compaction process opens SSTables before HCD completely writes them and uses them in place of the prior SSTables for any range previously written. Preemptive opening of SSTables helps to smoothly transfer reads between the SSTables by reducing cache churn and keeps hot rows hot.

A low value has a negative performance impact and will eventually cause heap pressure and GC activity. The optimal value depends on hardware and workload.

Default: 50MiB

Cache and read path index settings

prepared_statements_cache_size

Maximum size of the native protocol prepared statement cache.

If you see "prepared statements discarded in the last minute because cache limit reached" log messages, first investigate whether prepared statements are being used correctly with bind markers for variable parts. Only increase this value if you genuinely have more prepared statements than fit in the cache.

Default: Automatically calculated as the larger of 1/256th of heap or 10MiB

networking_cache_size

Maximum memory for inter-node and client-server networking buffers, expressed as a size. For example, 128MiB. Allocated from native memory in addition to heap.

Default: The smaller of 128MiB or 1/16th of heap

file_cache_enabled

Enables the SSTable chunk cache. When enabled, recently accessed sections of SSTables are stored in memory as uncompressed buffers to reduce disk I/O.

Default: true

column_index_size

Granularity of the collation index of rows within a partition, expressed as a size. For example, 4KiB. A smaller granularity results in faster row lookups within a partition at the cost of a larger index file.

Applies to both big and bti SSTable formats. For the big format, very small values are not recommended because large indexes cannot be cached efficiently.

Default: Not set (automatically uses 64KiB for big or 16KiB for bti). The HCD default configuration explicitly sets this to 4KiB.

file_cache_size

Maximum memory to use for caching SSTable chunks and buffer pools, expressed as a size. For example, 512MiB. Allocated from native memory in addition to heap. Requires file_cache_enabled: true.

Default: The smaller of 512MiB or 1/4th of heap

buffer_pool_use_heap_if_exhausted

When the SSTable buffer pool is exhausted (that is, when it has exceeded file_cache_size), controls whether buffers are allocated on-heap (true) or off-heap (false).

Default: true

cache_load_timeout

Maximum time the node waits for each cache (row, key, counter) to load at startup before timing out, expressed as a duration. Set to 0 to disable the timeout and wait indefinitely.

Default: 30s

key_cache_size

Maximum size of the key cache in memory, expressed as a size.

Key cache parameters only apply to the big SSTable format, which uses a partition key cache.

These parameters have no effect on the bti SSTable format because it doesn’t use a partition key cache. bti is the default SSTable format for HCD 2.0.

  • 0MiB (default): Disables the key cache.

  • Positive size: Maximum size of the key cache.

  • Not set: Automatically calculated as the smaller of 5% of heap or 100MiB for big format SSTables only.

key_cache_save_period

How often the key cache is saved to saved_caches_directory for the big SSTable format only. Saving the key cache greatly improves cold-start speeds with relatively low I/O cost.

  • 0: Disables saving the key cache.

  • Positive duration: How often the key cache is saved.

    Default: 4h (commented out by default; set explicitly to activate)

key_cache_keys_to_save

Number of keys from the key cache to save. Only relevant to the big SSTable format.

Default: Not set (all keys are saved)

row_cache_class_name

The classname of the row cache provider to use if row_cache_size and row_cache_save_period aren’t 0:

  • org.apache.cassandra.cache.OHCProvider (default): Fully off-heap.

  • org.apache.cassandra.cache.SerializingCacheProvider (legacy): Partially off-heap. Provided for backwards compatibility.

Use only row cache provider implementations bundled with HCD.

row_cache_size

Maximum size of the row cache in memory. The row cache can improve read latency, but it requires a significant amount of memory because it contains the entire row. Use the row cache only for frequently read rows or static rows. If the cache is too small, it might be too cold at startup and perform suboptimally until it has warmed up and recached the most frequently read rows.

  • 0 (default): Disable the row cache.

  • Positive number: Set the maximum size in MB of the row cache in memory.

row_cache_save_period

How often row cache keys are saved to saved_caches_directory, expressed as a duration. Only applies if row_cache_size is greater than 0.

  • 0s (default): Disables saving the row cache. Saving the row cache isn’t required to use the row cache, and it isn’t always recommended. Although the row cache will be cold at startup, you can warm it up by running preemptive reads on frequently accessed rows before accepting application traffic.

  • Positive duration: How often a row cache key is saved.

row_cache_keys_to_save

The number of keys from the row cache to save if row_cache_save_period is greater than 0.

The value 0 has a different meaning for row_cache_keys_to_save compared to other row_cache_* settings.

  • 0: All keys are saved.

  • Positive number: Saves the specified number of keys from the row cache.

Default: 100

counter_cache_size

The size of the counter cache. It doesn’t require as much memory as other caches because only the local (clock, count) tuple of a counter cell is kept in memory, not the whole counter.

  • Not set or empty (default): Automatically calculated as the smaller of 2.5 percent of heap or 50 MB.

  • Positive number: The size in MB of the counter cache in memory. If the cache is too small, it might be too cold at startup and perform suboptimally until it has warmed up and recached the most frequently updated counters.

  • 0: Disable the counter cache. The counter cache isn’t recommended for workloads with counter deletes that rely on a low gc_grace_seconds.

counter_cache_save_period

How often the database saves counter cache keys to saved_caches_directory, expressed as a duration. This keeps the cache warm through restarts.

  • 0: Disables saving the counter cache. This makes the cache cold at startup and the first writes will run slower because they must perform a full read-before-write and populate the cache.

  • Positive duration: How often a counter cache key is saved.

    Default: 7200s (2 hours)

counter_cache_keys_to_save

The number of keys from the counter cache to save if counter_cache_save_period is greater than 0.

The value 0 has a different meaning for counter_cache_keys_to_save compared to other counter_cache_* settings.

  • 0 (default): All keys are saved.

  • Positive number: Saves the specified number of keys from the counter cache.

Streaming settings

These settings apply to operations that perform file streaming, including repairs, bootstraps, and decommissions. These operations are mostly sequential I/O, which can saturate a node’s network bandwidth and degrade client (application) performance. Therefore, it is important to throttle streaming throughput.

inter_dc_stream_throughput_outbound

Maximum network bandwidth for streaming file transfers between datacenters, expressed as throughput. Set to a value less than or equal to stream_throughput_outbound.

Default: 24MiB/s (200 Mbps)

stream_entire_sstables

Enables the Zero Copy Streaming feature where eligible SSTables are streamed in their entirety between nodes instead of individual partitions, transferring data at a significantly faster rate.

This feature is enabled by default, is bound to the streaming throughput limits, and is disabled when internode encryption is enabled. When enabled, dependent properties such as entire_sstable_stream_throughput_outbound and entire_sstable_inter_dc_stream_throughput_outbound also take effect.

Default: true

stream_throughput_outbound

Maximum network bandwidth permitted for all outbound streaming file transfers on a node, expressed as throughput.

Default: 24MiB/s (200 Mbps)

entire_sstable_stream_throughput_outbound

Throttles entire SSTable outbound streaming transfers when stream_entire_sstables is enabled, expressed as throughput. Set to 0 to disable throttling.

Default: 24MiB/s (200 Mbps)

entire_sstable_inter_dc_stream_throughput_outbound

Throttles entire SSTable streaming between datacenters when stream_entire_sstables is enabled, expressed as throughput. Set to 0 to disable throttling.

Default: 24MiB/s (200 Mbps)

streaming_keep_alive_period

Time interval between keep-alive messages sent during streaming to prevent idle connections from being reset. A stream session is considered stalled and fails when no keep-alive message is received for two consecutive keep-alive periods. With the default of 300s, a stalled stream times out after 10 minutes.

Default: 300s

streaming_connections_per_host

The number of parallel connections used per remote host during streaming. Increase when joins are CPU-bound rather than network-bound, for example when a few nodes have large files.

Default: 1

Advanced properties

Less commonly-used settings normally reserved for experienced operators.

paxos_variant

The Paxos variant used for lightweight transactions (LWTs):

  • v1: Legacy Paxos. Expect 4 round trips for a write and 3 round trips for a read. For backward compatibility only.

  • v1_without_linearizable_reads_or_rejected_writes: Legacy Paxos with relaxed linearizability semantics.

  • v2 (default, recommended): Optimized Paxos. Expect 2 round trips for a write and 1 or 2 round trips for a read.

  • v2_without_linearizable_reads: Optimized Paxos; always 1 round trip for a read.

  • v2_without_linearizable_reads_or_rejected_writes: Optimized Paxos with relaxed linearizability semantics.

storage_compatibility_mode

Controls the storage format compatibility level used for SSTables, commit logs, hints, and other persistent files.

Available options:

  • CASSANDRA_4: Stays compatible with the Cassandra 4.x feature set, formats, and component versions.

  • UPGRADING: The cluster monitors node versions during a rolling upgrade. New features are enabled only after all nodes have been restarted in this mode.

  • NONE: All new features and formats are enabled immediately with no backward-compatibility overhead.

Because HCD 2.0 is based on Cassandra 5.0, HCD 2.0 deployments default to NONE. There are no Cassandra 4.x nodes in the cluster, so no backward compatibility is required. Use CASSANDRA_4 and the upgrade sequence below only when migrating an existing Cassandra 4.x cluster or an earlier HCD release to 2.0.

A typical upgrade from Cassandra 4.x to HCD 2.0:

  1. Do a rolling upgrade starting all nodes in CASSANDRA_4 compatibility mode.

  2. Once the new binary is stable, do a rolling restart in UPGRADING mode. New features are enabled once all nodes are in this mode.

  3. Do a rolling restart with all nodes in NONE mode to eliminate the version-check overhead.

    Default: NONE

trickle_fsync

Enables flushing portions of SSTables written using sequential writers when trickle_fsync_interval is reached. This minimizes sudden flushing of dirty buffers, which can impact read latencies.

Recommended for use with SSDs which can handle more frequent calls to fsync(), but may be detrimental to slow HDDs.

Default: true

trickle_fsync_interval

Threshold to trigger a flush when trickle_fsync is enabled, expressed as a size. For example, 10240KiB.

Default: 10240KiB (10 MiB)

batchlog_replay_throttle

Maximum rate at which the batchlog is replayed in aggregate across the cluster, expressed as throughput. For example, 1024KiB/s. The rate is reduced proportionally to the number of nodes in the cluster.

Default: 1024KiB/s

dynamic_snitch_update_interval

How often the dynamic snitch recalculates the more expensive part of host scores, expressed as a duration.

Default: 100ms

dynamic_snitch_reset_interval

How often the dynamic snitch resets all host scores, allowing a host with a temporarily poor score to recover, expressed as a duration.

Default: 600000ms (10 minutes)

dynamic_snitch_badness_threshold

Controls when the dynamic snitch stops preferring a "pinned" replica and switches to the fastest replica instead. Expressed as a decimal percentage: a value of 0.2 means the pinned host must be 20% worse than the fastest before the dynamic snitch switches away. Set to 0 to disable pinning.

Default: 1.0

batchlog_endpoint_strategy

Strategy used to choose the nodes that store batchlog replicas.

Available options:

  • random_remote: Default. Purely random, prevents the local rack when possible.

  • prefer_local: Random, except that one replica goes to the local rack, which offers lower availability guarantees.

  • dynamic_remote: Uses DynamicEndpointSnitch to select the fastest endpoints, prevents the local rack. Falls back to random_remote if dynamic snitch is not enabled.

  • dynamic: Same as dynamic_remote but does not exclude the local rack.

Default: dynamic_remote

rpc_keepalive

Enables TCP keepalive on native transport (CQL) and RPC connections.

Default: true

internode_compression

Controls whether traffic between nodes is compressed.

Available options:

  • dc (default): Compresses traffic between datacenters only.

  • all: Compresses all internode traffic.

  • none: Disables internode compression.

inter_dc_tcp_nodelay

Enables TCP_NODELAY for inter-datacenter communication. When false (default), multiple small packets are coalesced before sending, reducing TCP overhead at the cost of slightly higher latency for cross-DC responses.

Default: false

native_transport_allow_older_protocols

When true, HCD honors older but still supported native transport protocol versions.

Default: true

native_transport_max_threads

Maximum number of threads for handling native transport requests. Idle threads are stopped after 30 seconds, so there is no minimum setting.

Default: 128

native_transport_max_concurrent_connections

Maximum number of concurrent native transport (CQL) connections. Set to -1 for unlimited.

Default: -1

native_transport_max_concurrent_connections_per_ip

Maximum number of concurrent native transport (CQL) connections per source IP address. Set to -1 for unlimited.

Default: -1

uuid_sstable_identifiers_enabled

When true, newly created SSTables use UUID-based generation identifiers instead of sequential integers.

Once enabled, there is no straightforward way to downgrade.

Default: true

default_secondary_index

The default secondary index implementation used when CREATE INDEX does not specify one via USING:

  • sai (default): Storage-Attached Index, implemented via optimized SSTable/Memtable-attached indexes.

  • legacy_local_table: Legacy secondary index, implemented as a hidden table.

default_secondary_index_enabled

When true, allows using the default secondary index implementation. When false, CREATE INDEX must specify an implementation via USING.

Default: true

Request timeout settings

read_request_timeout

How long the coordinator waits for read operations to complete, expressed as a duration. For example, 5000ms. The lowest acceptable value is 10 ms.

Default: 5000ms

range_request_timeout

How long the coordinator waits for sequential scans or index scans to complete, expressed as a duration. The lowest acceptable value is 10 ms.

Default: 10000ms

write_request_timeout

How long the coordinator waits for write operations to complete, expressed as a duration. The lowest acceptable value is 10 ms.

Default: 2000ms

counter_write_request_timeout

How long the coordinator waits for counter write operations to complete, expressed as a duration. The lowest acceptable value is 10 ms.

Default: 5000ms

cas_contention_timeout

How long the coordinator retries a CAS (lightweight transaction) operation that contends with other proposals for the same row, expressed as a duration. The lowest acceptable value is 10 ms.

Default: 1000ms

truncate_request_timeout

How long the coordinator waits for truncations to complete, expressed as a duration. Because auto_snapshot is enabled by default, a flush must complete before the snapshot is taken. The lowest acceptable value is 10 ms.

Default: 60000ms

request_timeout

The default timeout for all other miscellaneous operations, expressed as a duration. The lowest acceptable value is 10 ms.

Default: 10000ms

native_transport_timeout

Upper bound on how long any request received via native transport is considered live and serviceable. When a request exceeds this limit, the server returns an OverloadedException to the client.

Default: 12000ms

aggregation_request_timeout

How long the coordinator waits for aggregation read operations, such as SELECT COUNT(*) and MIN(x), to complete.

Default: 120000ms

internode_timeout

Whether the coordinator and replicas exchange operation timeout information so that replicas can avoid processing requests that have already timed out on the coordinator. Corresponds to the legacy cross_node_timeout parameter (renamed in a prior release).

Default: true

slow_query_log_timeout

Threshold duration above which a slow read query is logged as a warning. Select queries that take longer than this threshold generate an aggregated log message to identify slow queries. Set to 0 to disable slow query logging.

Default: 500ms

internode_tcp_connect_timeout

Timeout for establishing internode TCP connections, expressed as a duration.

Default: 2000ms

internode_tcp_user_timeout

Only supported on Linux with epoll.

Maximum time that unacknowledged data can remain on an established internode connection before the connection is discarded, expressed as a duration.

Set to 0 to use the OS default (net.ipv4.tcp_retries2).

Default: 30000ms

internode_streaming_tcp_user_timeout

Maximum time unacknowledged data can remain on a streaming internode connection before the connection is discarded, expressed as a duration. Set to 0 to increase the timeout (uses OS default).

Default: 300000ms (5 minutes)

native_transport_port_ssl (deprecated)

A dedicated port for encrypted native transport (CQL) connections when client_encryption_options.enabled is true. If set to a different value than native_transport_port, then the standard port remains unencrypted and this port carries encrypted traffic only.

This deprecated parameter will be removed in a future release. The native_transport_port can handle both encrypted and unencrypted connections. For more information, see Secure database ports.

Default: 9142

native_transport_max_frame_size

Maximum allowed size of a native transport (CQL) frame. Requests larger than this value are rejected as invalid.

Default: 16MiB

native_transport_idle_timeout

Idle connection timeout for native transport (CQL) connections. Connections that have had no reads or writes for this duration are closed. Clients can prevent closure by sending an OPTIONS request (heartbeat) within the timeout window.

Default: Not set (idle connections are never closed)

native_transport_rate_limiting_enabled

Enables rate limiting for native transport (CQL) requests. When enabled, requests that exceed native_transport_max_requests_per_second are rejected.

Default: false

native_transport_max_requests_per_second

Maximum number of native transport (CQL) requests per second across the node. Requires native_transport_rate_limiting_enabled: true.

Default: 1000000

internode_socket_send_buffer_size

Size of the TCP send buffer for internode communication, expressed as a size. For example, 1MiB. When not set, the OS default (net.ipv4.tcp_wmem) is used.

Default: Not set (OS default)

internode_socket_receive_buffer_size

Size of the TCP receive buffer for internode communication, expressed as a size. For example, 1MiB. When not set, the OS default (net.ipv4.tcp_rmem) is used.

Default: Not set (OS default)

internode_application_send_queue_capacity

Per-link capacity of the internode send queue, expressed as a size. For example, 4MiB. Each node pair has three links (urgent, small, large).

Default: 4MiB

internode_application_send_queue_reserve_endpoint_capacity

Per-endpoint reserve capacity for the internode send queue, expressed as a size. Limits total queued messages to or from a single peer node.

Default: 128MiB

internode_application_send_queue_reserve_global_capacity

Global reserve capacity for all internode send queues, expressed as a size.

Default: 512MiB

internode_application_receive_queue_capacity

Per-link capacity of the internode receive queue, expressed as a size.

Default: 4MiB

internode_application_receive_queue_reserve_endpoint_capacity

Per-endpoint reserve capacity for the internode receive queue, expressed as a size.

Default: 128MiB

internode_application_receive_queue_reserve_global_capacity

Global reserve capacity for all internode receive queues, expressed as a size.

Default: 512MiB

concurrent_merkle_tree_requests

The number of simultaneous Merkle tree requests allowed during repair.

Default: Not set (uses a calculated default based on available cores)

repair_session_space

Maximum memory used for repair session state, expressed as a size. For example, 128MiB. Commented out by default; the calculated default is 1/16th of the heap. A smaller value reduces resolution of repair trees, which can cause over-streaming.

Default: 1/16th of heap

retries

Configuration block for retry behavior during repair sessions. Set in the repair section`. For example:

repair:
  retries:
    enabled: true
    max_retries: 3

Default: Disabled (no automatic retry)

Security properties

Configure authentication, authorization, and role management.

The security properties in cassandra.yaml control how HCD handles user authentication, authorization, and data encryption. These settings are crucial for securing your cluster in production environments.

Authentication properties

authenticator

The authentication backend that implements IAuthenticator to identify users.

HCD provides several authentication options:

  • AllowAllAuthenticator: Performs no authentication checks. Use this to disable authentication. DataStax does not recommend this for production environments.

  • PasswordAuthenticator: Relies on username/password pairs stored in the system_auth.roles table.

  • AdvancedAuthenticator (default): Allows multiple authentication schemes simultaneously, including internal, OIDC, LDAP, and mutual TLS. The active schemes are controlled by default_scheme and additional_schemes. For mTLS configuration, see mTLS authentication.

    Default: AdvancedAuthenticator

    If using PasswordAuthenticator, you must also use CassandraRoleManager for role management. Increase the system_auth keyspace replication factor when using authentication.

Authorization properties

authorizer

The authorization backend that implements IAuthorizer to limit access and provide permissions:

  • AllowAllAuthorizer (not recommended): Allows any action to any user. Use this to disable authorization. DataStax does not recommend this for production environments.

  • CassandraAuthorizer: Stores permissions in the system_auth.role_permissions table.

    If using CassandraAuthorizer, increase the system_auth keyspace replication factor.

  • AdvancedAuthorizer (default): Checks if roles have authorization permissions to access resources.

    authorizer:
      class_name: com.datastax.cassandra.auth.AdvancedAuthorizer
      parameters:
        enabled: true

Role management properties

role_manager

The role management backend that implements IRoleManager to maintain grants and memberships between roles:

  • CassandraRoleManager: Stores role data in the system_auth keyspace.

  • AdvancedRoleManager (default): Fetches roles from internal Cassandra tables and/or external servers.

    Most IRoleManager functions require an authenticated login. If the configured IAuthenticator doesn’t implement authentication, most functionality is unavailable.

Network authorization properties

internode_authenticator

The backend for authenticating and authorizing internode connections. This is now a block with class_name and optional parameters subproperties. For mTLS configuration examples, see Configure mTLS authentication.

internode_authenticator:
  class_name: org.apache.cassandra.auth.AllowAllInternodeAuthenticator
  parameters: {}

Default: AllowAllInternodeAuthenticator

network_authorizer

The network authorization backend that implements INetworkAuthorizer to restrict user access to certain datacenters. This is now a block with a class_name subproperty:

network_authorizer:
  class_name: org.apache.cassandra.auth.AllowAllNetworkAuthorizer
  • AllowAllNetworkAuthorizer (default): Allows access to any datacenter to any user.

  • CassandraNetworkAuthorizer: Stores permissions in the system_auth.network_permissions table.

CIDR authorization properties

cidr_authorizer

The CIDR authorization backend that implements ICIDRAuthorizer to restrict user access from certain CIDR ranges. Use a block with class_name subproperty rather than setting the class name as the literal value:

cidr_authorizer:
  class_name: org.apache.cassandra.auth.AllowAllCIDRAuthorizer
  • AllowAllCIDRAuthorizer (default): Allows access from any CIDR to any user. Use this to disable CIDR authorization.

  • CassandraCIDRAuthorizer: Stores CIDR permissions in the system_auth.cidr_permissions table. Enables setting of cidr_* subparameters.

    If using CassandraCIDRAuthorizer, increase the system_auth keyspace replication factor.

cidr_checks_for_superusers

Requires cidr_authorizer: CassandraCIDRAuthorizer.

Whether CIDR authorization is enforced for superusers and non-superusers.

CIDR checks cannot be performed for JMX calls.

Default: false

cidr_authorizer_mode

Requires cidr_authorizer: CassandraCIDRAuthorizer.

Controls how CIDR violations are handled:

  • MONITOR (default): CIDR checks are logged but not enforced. Access is permitted regardless.

  • ENFORCE: Access is rejected if the source IP is not in an authorized CIDR group.

cidr_groups_cache_refresh_interval

Requires cidr_authorizer: CassandraCIDRAuthorizer.

Refresh interval, in minutes, for the CIDR groups cache.

Default: 5

ip_cache_max_size

Requires cidr_authorizer: CassandraCIDRAuthorizer.

Maximum entries in the IP-to-CIDR-groups cache.

Default: 100

traverse_auth_from_root

When true, authorization checks for nested resources (such as a column in a table in a keyspace) traverse the entire resource hierarchy from root, checking permissions at each level. When false, checks start from the most specific resource.

Default: false

Client encryption properties

client_encryption_options

Configure client-to-server encryption settings.

client_encryption_options:
    enabled: false                    # Enable client-to-server encryption
    optional: true                    # Allow encrypted and unencrypted connections
    keystore: conf/.keystore         # Path to keystore file
    keystore_password: cassandra     # Keystore password (CHANGE THIS)
    require_client_auth: false        # Verify client certificates
    truststore: conf/.truststore     # Path to truststore file
    truststore_password: cassandra   # Truststore password (CHANGE THIS)
    protocol: TLS                     # SSL/TLS protocol
    store_type: JKS                   # Keystore type
    cipher_suites: [                 # Supported cipher suites
        TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
        TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    ]
    # ssl_context_factory:           # Optional: custom SSL context factory
    #   class_name: ...

The default configuration is insecure. Generate proper keystores and truststores before enabling encryption in production. The default keystore password cassandra is insecure. If you enable require_client_auth: true, change the keystore and truststore passwords before deploying.

Server encryption properties

server_encryption_options

Configure server-to-server internode encryption settings.

server_encryption_options:
    internode_encryption: none        # Encryption scope: none, dc, rack, or all
    optional: true                    # Allow encrypted and unencrypted connections
    keystore: conf/.keystore         # Path to keystore file (uncommented by default)
    keystore: conf/.keystore         # Path to keystore file
    keystore_password: cassandra     # Don't use the default keystore password
    require_client_auth: false        # Verify peer server certificates
    truststore: conf/.truststore     # Path to truststore file
    truststore_password: cassandra   # Don't use the default truststore password
    require_endpoint_verification: false  # Verify hostname in certificate
    legacy_ssl_storage_port_enabled: false # Enable legacy SSL storage port (upgrade only)
    # outbound_keystore: conf/.keystore        # Separate keystore for outbound connections
    # outbound_keystore_password: cassandra        # Don't use the default password.
    # ssl_context_factory:
    #   class_name: ...

internode_encryption supports the following scope options:

  • none: Do not encrypt outgoing connections

  • dc: Encrypt connections to peers in other datacenters, but not within datacenters

  • rack: Encrypt connections to peers in other racks, but not within racks

  • all: Always use encrypted connections

legacy_ssl_storage_port_enabled replaces the deprecated enable_legacy_ssl_storage_port parameter. Set legacy_ssl_storage_port_enabled to true only during a rolling upgrade if some nodes still use the legacy SSL storage port.

The default configuration is insecure. By default, the keystore and keystore_password entries are uncommented and use the publicly known default password cassandra. Don’t use the default keystore or truststore passwords. Generate keystores and truststores with secure passwords before enabling encryption in production.

Transparent data encryption properties

transparent_data_encryption_options

Configure transparent data encryption (TDE) for data at rest.

transparent_data_encryption_options:
    enabled: false                    # Enable transparent data encryption
    chunk_length_kb: 64              # Encryption chunk size
    cipher: AES/CBC/PKCS5Padding     # Encryption cipher
    key_alias: testing:1             # Key alias for encryption
    iv_length: 16                    # CBC IV length for AES
    key_provider:
      - class_name: org.apache.cassandra.security.JKSKeyProvider
        parameters:
          - keystore: conf/.keystore
            keystore_password: cassandra
            store_type: JCEKS
            key_password: cassandra

To use the HCD TDE feature, make sure the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy is enabled. In JDK 8u161 and later, this is enabled by default.

This feature supports encryption for commit log and hints files.

Audit logging properties

audit_logging_options

Configure audit logging to track CQL commands and authentication events.

audit_logging_options:
    enabled: false                    # Enable audit logging
    logger:
      - class_name: BinAuditLogger   # Audit logger implementation
    audit_logs_dir:                  # Directory for audit logs
    included_keyspaces:              # Keyspaces to audit
    excluded_keyspaces: system, system_schema, system_virtual_schema
    included_categories:             # Categories to audit
    excluded_categories:             # Categories to exclude
    included_users:                  # Users to audit
    excluded_users:                  # Users to exclude
    roll_cycle: HOURLY              # Log roll cycle
    block: true                      # Block on log write
    max_queue_weight: 268435456     # Max queue weight (256 MiB)
    max_log_size: 17179869184       # Max log size (16 GiB)
    archive_command:                 # Archive command
    max_archive_retries: 10         # Max archive retries
trace_type_query_ttl

Time-to-live for query trace entries in the system_traces.events table, expressed as a duration.

Default: 1d

trace_type_repair_ttl

Time-to-live for repair trace entries in the system_traces.events table, expressed as a duration.

Default: 7d

Security cache properties

roles_validity

Validity period for the roles cache, expressed as a duration.

HCD caches granted roles for authenticated sessions. After this period, they become eligible for async reload.

Set to 0 to disable roles caching.

Default: 2000ms

permissions_validity

Validity period for the permissions cache, expressed as a duration.

Set to 0 to disable permissions caching.

Default: 2000ms

credentials_validity

Validity period for the credentials cache, expressed as a duration.

HCD tightly couples this cache to the PasswordAuthenticator implementation.

Set to 0 to disable credentials caching.

Default: 2000ms

roles_update_interval

Refresh interval for the roles cache, expressed as a duration.

After this interval, cache entries become eligible for refresh.

Default: roles_validity

roles_cache_active_update

When true, the roles cache is updated proactively in the background before entries expire, rather than waiting for the first access after expiry.

Default: false

permissions_update_interval

Refresh interval for the permissions cache, expressed as a duration.

After this interval, cache entries become eligible for refresh.

Default: permissions_validity

permissions_cache_active_update

When true, the permissions cache is updated proactively in the background before entries expire, rather than waiting for the first access after expiry.

Default: false

credentials_update_interval

Refresh interval for the credentials cache, expressed as a duration.

After this interval, cache entries become eligible for refresh.

Default: credentials_validity

credentials_cache_active_update

When true, the credentials cache is updated proactively in the background before entries expire.

Default: false

User-defined functions (UDF)

Configure user-defined functions (UDFs) that allow custom logic to be executed within the database.

user_defined_functions_enabled

Enables user-defined functions (UDFs) on this node.

Default: true

Memory leak detection settings

Configure garbage collection monitoring and memory leak detection thresholds. These properties are commented out by default in cassandra.yaml, which means they are inactive or use their default values. Uncomment and configure them as needed for your environment.

gc_log_threshold

HCD logs GC pauses greater than this threshold at INFO level. Expressed as a duration.

This threshold can be adjusted to minimize logging if necessary.

Default: 200ms

gc_warn_threshold

HCD logs GC pauses greater than this threshold at WARN level. Expressed as a duration.

Adjust the threshold based on your application throughput requirements. Setting to 0 deactivates the feature.

Default: 1000ms

max_value_size

The maximum size of any value in SSTables. If any value exceeds this threshold, HCD marks the SSTable as corrupted. Must be positive and less than 2 GiB.

Default: 256MiB

default_keyspace_rf

Default replication factor applied when creating a keyspace that does not explicitly specify one. Also applied when altering a keyspace from NetworkTopologyStrategy to SimpleStrategy without an explicit replication factor. Affects system keyspaces: system_traces and system_distributed use the higher of 2 or this value; system_auth uses the higher of 1 or this value.

Default: 1

ideal_consistency_level

Tracks a per-keyspace metric indicating whether replication achieved the ideal consistency level for writes without timing out.

Default: Not set (metric is not tracked)

automatic_sstable_upgrade

When true, HCD automatically upgrades the oldest non-upgraded SSTables to the latest version when there is no ordinary compaction to perform.

Default: false

max_concurrent_automatic_sstable_upgrades

Limits the number of SSTables that can be automatically upgraded concurrently when automatic_sstable_upgrade is true.

Default: 1

corrupted_tombstone_strategy

Controls what happens when a corrupted tombstone is encountered during reads or compaction.

Available options: disabled, warn, exception.

Default: disabled

auth_read_consistency_level

Consistency level used for reads from auth tables (system_auth).

Default: LOCAL_QUORUM

auth_write_consistency_level

Consistency level used for writes to auth tables (system_auth).

Default: EACH_QUORUM

auth_cache_warming_enabled

When true, HCD pre-warms the auth caches during node startup before the node is considered fully available. Prevents a thundering herd problem when many clients reconnect simultaneously after a node restart.

Default: false

read_thresholds_enabled

Enables tracking of read sizes across replicas, which allows the coordinator to warn or fail queries that materialize more data than the configured thresholds. When enabled, the following sub-parameters become active: coordinator_read_size_warn_threshold, coordinator_read_size_fail_threshold, local_read_size_warn_threshold, local_read_size_fail_threshold, row_index_read_size_warn_threshold, row_index_read_size_fail_threshold.

Default: false

coordinator_read_size_warn_threshold

When read_thresholds_enabled is true, warns the client if the materialized size of a query on the coordinator exceeds this value.

Default: Not set (disabled)

coordinator_read_size_fail_threshold

When read_thresholds_enabled is true, fails the query if the materialized size of a query on the coordinator exceeds this value.

Default: Not set (disabled)

local_read_size_warn_threshold

When read_thresholds_enabled is true, warns if the local read heap size exceeds this value.

Default: Not set (disabled)

local_read_size_fail_threshold

When read_thresholds_enabled is true, fails the query if the local read heap size exceeds this value.

Default: Not set (disabled)

row_index_read_size_warn_threshold

When read_thresholds_enabled is true, warns if the expected memory size of the RowIndexEntry exceeds this value.

Default: Not set (disabled)

row_index_read_size_fail_threshold

When read_thresholds_enabled is true, fails the query if the expected memory size of the RowIndexEntry exceeds this value.

Default: Not set (disabled)

use_statements_enabled

Whether USE <keyspace> CQL statements are allowed.

Default: true

client_error_reporting_exclusions

Configures subnets whose clients are excluded from incrementing the client protocol error metrics.

client_error_reporting_exclusions:
  subnets:
    - 127.0.0.1
    - 127.0.0.0/31

Default: Not set (all clients increment metrics)

startup_checks

Configuration block to enable or disable individual startup checks that run when HCD starts.

Available checks:

  • check_filesystem_ownership: Verifies correct ownership of attached disk locations at startup.

  • check_dc: Prevents startup if the snitch’s datacenter differs from the previously recorded datacenter.

  • check_rack: Prevents startup if the snitch’s rack differs from the previously recorded rack.

  • check_data_resurrection: Fails startup if the node has been down longer than gc_grace_seconds, which could cause data resurrection.

Default: All checks use their documented defaults (see YAML comments)

Guardrails

Guardrails are system limits that ensure high availability and optimal performance of the database. They help prevent operations that could cause performance issues or system instability. For more information, see HCD guardrails.

hcd_guardrail_defaults

Whether to automatically apply default guardrail values that are optimized for HCD production environments according to DataStax recommendations.

Default: true

Query guardrails

tombstone_warn_threshold

Log a warning when scanning more tombstones than this threshold.

When executing a scan, within or across a partition, Cassandra keeps tombstones in memory to return them to the coordinator. With workloads that generate many tombstones, this can cause performance problems and even exhaust the server heap.

Default: 1000

tombstone_failure_threshold

Fail queries that scan more tombstones than this threshold.

Default: 100000

replica_filtering_protection

Configuration block for replica filtering protection. This guardrail materializes replica results on-heap at the coordinator during filtering or secondary index queries at consistency levels above ONE or LOCAL_ONE. This ensures correct results even when replicas are stale, but can use significant heap for large result sets.

replica_filtering_protection:
  cached_rows_warn_threshold: 2000
  cached_rows_fail_threshold: 32000

Set the following subparameters in replica_filtering_protection:

  • cached_rows_warn_threshold: Per-query threshold (number of rows materialized across all replicas) above which a warning is logged. *

    Default: 2000

  • cached_rows_fail_threshold: Per-query threshold above which the query fails. If queries fail due to exceeding this threshold, either reduce the page size or repair the stale replica.

    Default: 32000

page_size_warn_threshold

Warning threshold for the number of rows in a page. Set to -1 to disable.

Default: -1 (disabled)

page_size_fail_threshold

Failure threshold to prevent paging queries that request more rows than this limit. Set to -1 to disable.

Default: -1 (disabled)

offset_rows_warn_threshold

Warning threshold for the number of rows skipped by LIMIT/OFFSET paging.

Default: 10000

offset_rows_failure_threshold

Failure threshold to prevent LIMIT/OFFSET paging from skipping more rows than this limit.

Default: 20000

in_select_cartesian_product_warn_threshold

Warning threshold for the cartesian product size of an IN query.

Example: "a in (1,2,…​10) and b in (1,2…​10)" results in a cartesian product of 100.

Default: -1 (disabled)

in_select_cartesian_product_fail_threshold

Failure threshold to prevent IN queries whose cartesian product exceeds this limit.

Default: -1 (disabled)

partition_keys_in_select_warn_threshold

Warning threshold for the number of partition keys in an IN query.

Default: -1 (disabled)

partition_keys_in_select_fail_threshold

Failure threshold to prevent IN queries selecting more partition keys than this limit.

Default: -1 (disabled)

batch_size_warn_threshold

Log WARN on any multiple-partition batch size that exceeds this value.

Use caution when increasing this threshold as it can lead to node instability.

Default: 5KiB

batch_size_fail_threshold

Fail any multiple-partition batch that exceeds this value.

Default: 50KiB (10 times the default batch_size_warn_threshold)

unlogged_batch_across_partitions_warn_threshold

Log WARN on any batches not of type LOGGED that span across more partitions than this limit.

Default: 10

column_value_size_warn_threshold

Warning threshold for the size of an individual column value, such as 1MiB.

Default: null (disabled)

column_value_size_fail_threshold

Failure threshold to prevent writing column values larger than this size, such as 1MiB.

Default: null (disabled)

write_consistency_levels_warned

Logs a warning when write queries use the specified consistency levels.

Default: None warned

write_consistency_levels_disallowed

Prevents write queries with the specified consistency levels.

Default: All consistency levels are allowed

read_consistency_levels_warned

Logs a warning when read queries use the specified consistency levels.

Default: None warned

read_consistency_levels_disallowed

Prevents read queries with the specified consistency levels.

Default: All consistency levels are allowed

read_before_write_list_operations_enabled

Whether to allow read-before-write operations, such as setting a list element by index or removing a list element by index or value.

Note: Lightweight Transactions (LWT) are always allowed.

Default: true

user_timestamps_enabled

Whether to allow user-provided timestamps in write requests.

Default: true

Table definition guardrails

columns_per_table_warn_threshold

Warning threshold for tables that have more than this number of columns.

Default: -1 (disabled)

columns_per_table_fail_threshold

Failure threshold to prevent tables from having more than this number of columns.

Default: -1 (disabled)

collection_size_warn_threshold

Warning threshold for the size of a collection column, expressed as a size. For example, 1MiB.

Default: null (disabled)

collection_size_fail_threshold

Failure threshold for the size of a collection column, expressed as a size. For example, 1MiB.

Default: null (disabled)

items_per_collection_warn_threshold

Warning threshold for the number of elements in a collection.

Default: -1 (disabled)

items_per_collection_fail_threshold

Failure threshold for the number of elements in a collection.

Default: -1 (disabled)

tables_warn_threshold

Warning threshold for the total number of user tables.

Default: -1 (disabled)

tables_fail_threshold

Failure threshold to prevent creating more tables than this limit.

Default: -1 (disabled)

table_properties_disallowed

Prevents creating tables with the specified properties.

Default: All properties are allowed

zero_ttl_on_twcs_enabled

Whether to allow CREATE TABLE or ALTER TABLE statements that set default_time_to_live = 0 on a table using TimeWindowCompactionStrategy.

When false, such statements fail.

Default: true

zero_ttl_on_twcs_warned

Whether to emit a warning when a CREATE TABLE or ALTER TABLE statement sets default_time_to_live = 0 on a table using TimeWindowCompactionStrategy.

Only relevant when zero_ttl_on_twcs_enabled is true.

Default: true

dynamic_data_masking_enabled

Whether to enable dynamic data masking (DDM), which allows CQL masking functions to be attached to table columns.

Users without the UNMASK permission see an obscured version of values in masked columns. Existing masks are ignored at query time when this is false, but masks can still be dropped.

Default: true

vector_dimensions_warn_threshold

Warning threshold for the number of dimensions in a vector column.

Default: -1 (disabled)

vector_dimensions_fail_threshold

Failure threshold to prevent creating vector columns with more dimensions than this limit.

Default: 8192

Keyspace guardrails

keyspaces_warn_threshold

Warning threshold for the total number of user keyspaces.

Default: -1 (disabled)

keyspaces_fail_threshold

Failure threshold to prevent creating more keyspaces than this limit.

Default: -1 (disabled)

minimum_replication_factor_warn_threshold

Warning threshold when a keyspace is created or altered with a replication factor less than this value.

Default: -1 (disabled)

minimum_replication_factor_fail_threshold

Failure threshold to prevent creating keyspaces with a replication factor less than this value.

Default: -1 (disabled)

maximum_replication_factor_warn_threshold

Warning threshold when a keyspace is created or altered with a replication factor greater than this value.

Default: -1 (disabled)

maximum_replication_factor_fail_threshold

Failure threshold to prevent creating keyspaces with a replication factor greater than this value.

Default: -1 (disabled)

fields_per_udt_warn_threshold

Warning threshold for the number of fields in a user-defined type.

Default: -1 (disabled)

fields_per_udt_fail_threshold

Failure threshold to prevent a user-defined type from having more than this number of fields.

Default: -1 (disabled)

Indexing and materialized view guardrails

secondary_indexes_per_table_warn_threshold

Warning threshold for the number of secondary indexes per table. Does not apply to CUSTOM INDEX StorageAttachedIndex.

Default: -1 (disabled)

secondary_indexes_per_table_fail_threshold

Failure threshold to prevent creating more secondary indexes per table than this limit. Does not apply to CUSTOM INDEX StorageAttachedIndex.

Default: -1 (disabled)

sai_indexes_per_table_warn_threshold

Warning threshold for the number of StorageAttachedIndex (SAI) indexes per table. Only applies to CUSTOM INDEX StorageAttachedIndex.

Default: -1 (disabled)

sai_indexes_per_table_fail_threshold

Failure threshold for the number of StorageAttachedIndex per table. Only applies to CUSTOM INDEX StorageAttachedIndex.

Default: 10

sai_indexes_total_warn_threshold

Warning threshold for the total number of StorageAttachedIndex across all keyspaces.

Default: -1 (disabled)

sai_indexes_total_fail_threshold

Failure threshold for the total number of StorageAttachedIndex across all keyspaces.

Default: 100

sai_sstable_indexes_per_query_warn_threshold

Warning threshold for the number of SAI SSTable indexes referenced on a replica when executing a SELECT query.

Default: 32

sai_sstable_indexes_per_query_fail_threshold

Failure threshold for the number of SAI SSTable indexes referenced on a replica when executing a SELECT query. Set to -1 to disable.

Default: -1 (disabled)

non_partition_restricted_index_query_enabled

Whether to allow secondary index queries that do not restrict on a partition key.

Default: true

materialized_views_per_table_warn_threshold

Warning threshold for the number of materialized views per table.

To disable materialized views entirely on this node, set materialized_views_per_table_fail_threshold: 0. For more information, see Hyper-Converged Database (HCD) guardrails.

Default: -1 (disabled)

materialized_views_per_table_fail_threshold

Failure threshold to prevent creating more materialized views per table than this limit. Set to 0 to disallow materialized views entirely on this node.

Default: -1 (disabled)

Partition size guardrails

partition_size_warn_threshold

Log a warning when compacting partitions larger than this value.

Default: 100MiB

partition_size_fail_threshold

Fail operations that produce partitions larger than this value, such as 1GiB.

Default: null (disabled)

Data directory disk usage guardrails

data_disk_usage_percentage_warn_threshold

Warning threshold when local data disk usage exceeds this percentage. Valid values are 1 to 100.

This only applies to data directories, not to disks used for the commit log, hints, or saved caches.

Default: -1 (disabled)

data_disk_usage_percentage_fail_threshold

Failure threshold to reject write requests if replica disk usage exceeds threshold. Valid values are 1 to 100.

Default: -1 (disabled)

data_disk_usage_max_disk_size

Maximum disk size used as the basis for calculating data_disk_usage_percentage_warn_threshold and data_disk_usage_percentage_fail_threshold, expressed as a size. For example, 500GiB.

When set, the thresholds become percentages of this fixed size rather than the physically available disk size.

Default: null (disabled; uses the physically available disk size)

Experimental features

These features are disabled by default and are not recommended for production use.

transient_replication_enabled

Enables creation of transiently replicated keyspaces on this node. Transient replication uses a reduced number of full replicas and additional "transient" replicas that hold only unrepaired data.

Default: false

materialized_views_enabled

Enables creating materialized views on this node.

Default: false

You can also control materialized view creation with the materialized_views_per_table_fail_threshold guardrail.

drop_compact_storage_enabled

Enables the ALTER TABLE …​ DROP COMPACT STORAGE statement on this node.

Default: false

Diagnostic and operational properties

Heap dump settings

heap_dump_path

The directory where HCD writes heap dump files.

Default: Not set (heap dumps are written to the HCD home directory)

dump_heap_on_uncaught_exception

When true, HCD automatically triggers a heap dump when an uncaught exception causes the JVM to terminate.

Default: false

diagnostic_events_enabled

When true, enables diagnostic event emission for troubleshooting operational issues. Diagnostic events contain details on internal state and temporal relationships across events, and are accessible by clients via JMX.

Default: false

repaired_data_tracking_for_range_reads_enabled

Whether to track the repaired data state during range reads. Mismatches between the repaired datasets across replicas are reported as confirmed or unconfirmed.

If true, all range reads include repaired data tracking, which adds overhead. To minimize the additional overhead, consider enabling repaired_data_tracking_for_partition_reads_enabled instead.

Default: false

repaired_data_tracking_for_partition_reads_enabled

Whether to track repaired data state during partition reads.

If true, partition reads are tracked only at consistency levels greater than ONE or LOCAL_ONE and a digest mismatch occurs. In terms of overhead, this is more efficient than tracking all range reads.

Default: false

report_unconfirmed_repaired_data_mismatches

When true, records a separate metric for unconfirmed repaired data mismatches in addition to confirmed ones. Unconfirmed mismatches can occur due to pending repair sessions or unrepaired partition tombstones, and they are less likely to require intervention than confirmed mismatches.

Default: false

Disk access mode

disk_access_mode

The disk access mode for reading SSTable data files. This is separate from commitlog_disk_access_mode, which controls commit log access.

Available options:

  • mmap_index_only (default): Memory-maps only the index files; uses standard I/O for data files. This is the recommended setting for most deployments.

  • mmap: Memory-mapped I/O for all SSTable files.

  • standard: Standard I/O.

  • auto: Selects the optimal mode based on the platform and configuration.

Default: mmap_index_only

Crypto provider

crypto_provider

Configuration block to install a cryptographic provider at startup. By default, HCD installs the DefaultCryptoProvider, which uses the Amazon Corretto Crypto Provider (ACCP) where available and falls back to the JRE default if ACCP is not present. To force a failure when the provider is not installed properly, set fail_on_missing_provider to "true". To bypass the installation of a crypto provider entirely, use org.apache.cassandra.security.JREProvider.

crypto_provider:
  - class_name: org.apache.cassandra.security.DefaultCryptoProvider
    parameters:
      - fail_on_missing_provider: "false"

Default: DefaultCryptoProvider with fail_on_missing_provider: "false"

Streaming state system view

streaming_state_expires

How long completed streaming session state is retained in the system_views.streaming table, expressed as a duration.

Default: Not set (entries expire after a calculated default)

streaming_state_size

Maximum number of streaming session entries to retain in the system_views.streaming table.

Default: Not set (uses a calculated default)

streaming_stats_enabled

Whether streaming statistics are tracked and exposed through the system_views.streaming table.

Default: true

Denylist settings

The following properties allow operators to block specific partition-level operations by adding entries to the system.denylist_table table.

partition_denylist_enabled

Whether partition-level denylisting is enabled.

Default: false

denylist_max_keys_per_table

Maximum number of denylist entries per table. Nodes warn when this limit is exceeded but continue to allow new entries.

Default: 1000

denylist_max_keys_total

Maximum total number of denylist entries across all tables.

Default: 10000

denylist_refresh

How often the in-memory denylist cache is refreshed from the system.denylist_table table, expressed as a duration. This serves as a fail-safe; the recommended pattern is to call the refresh API explicitly after any changes to denylist entries.

Default: 600s

denylist_initial_load_retry

How often to retry loading the denylist from the system table during node startup if the initial load fails, expressed as a duration.

Default: 5s

denylist_writes_enabled

Whether write denylisting is enabled when partition_denylist_enabled is true.

Default: true

denylist_reads_enabled

Whether read denylisting is enabled when partition_denylist_enabled is true.

Default: true

denylist_range_reads_enabled

Whether range read denylisting is enabled when partition_denylist_enabled is true.

Default: true

denylist_consistency_level

The consistency level used when reading from the system.denylist_table table.

Default: QUORUM

Was this helpful?

Give Feedback

How can we improve the documentation?

© Copyright IBM Corporation 2026 | Privacy policy | Terms of use Manage Privacy Choices

Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Apache Solr, Apache Hadoop, Hadoop, Apache Pulsar, Pulsar, Apache Spark, Spark, Apache TinkerPop, TinkerPop, Apache Kafka and Kafka are either registered trademarks or trademarks of the Apache Software Foundation or its subsidiaries in Canada, the United States and/or other countries. Kubernetes is the registered trademark of the Linux Foundation.

General Inquiries: Contact IBM