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.

Configures the schedulers in charge of querying for expired records, removing expired records, and the execution of the checks.

Time interval in seconds to check for expired data in seconds.

The number of seconds to delay the first TTL check to speed up start-up time.

The maximum number of documents to check and delete per batch by the TTL rebuild thread. All expired documents are deleted from the index during each check. To avoid memory pressure, their unique keys are retrieved and then deletes are issued in batches.

The maximum number of search indexes (cores) that can execute TTL cleanup concurrently. Manages system resource consumption and prevents many search cores from executing simultaneous TTL deletes.

Configures the maximum file size of the search index config or schema. Resource files can be uploaded, but the search index config and schema are stored internally in the database after upload.

The maximum time, in minutes, to wait for the flushing of asynchronous index updates that occurs at DSE Search commit time or at flush time.

The maximum time, in minutes, to wait for each DSE Search index to load on startup or create/reload operations. This advanced option should be changed only if exceptions happen during search index loading.

Whether to apply the configured disk failure policy if IOExceptions occur during index update operations.

The directory to store index data. See Managing the location of DSE Search data. By default, each DSE Search index is saved in <solr_data_dir>/<keyspace_name>.<table_name> or as specified by the dse.solr.data.dir system property.

The Apache Lucene® field cache is deprecated. Instead, for fields that are sorted, faceted, or grouped by, set docValues="true" on the field in the search index schema. Then reload the search index and reindex.

For DSE Search, configure whether to asynchronously reindex bootstrapped data.

Configuration options include:

How long the coordinator waits for read operations to complete before timing it out.

Security options for DSE Search. See DSE Search security checklist.

Tunes encryption of search indexes.

Allocates shared DSE Search decryption cache off JVM heap.

The maximum size of the shared DSE Search decryption cache in megabytes (MB).

Used by the Tomcat application container to run DSE Search. The Tomcat web server uses the GSSAPI mechanism (SPNEGO) to negotiate the GSSAPI security mechanism (Kerberos). <REALM> is the name of your Kerberos realm. In the Kerberos principal, <REALM> must be uppercase.

Used by the Tomcat application container to run DSE Search. The Tomcat web server uses the GSSAPI mechanism (SPNEGO) to negotiate the GSSAPI security mechanism (Kerberos). REALM is the name of your Kerberos realm. In the Kerberos principal, REALM must be uppercase.

Internode communication between DSE Search nodes.

Fault tolerance option for internode communication between DSE Search nodes.

Timeout behavior during distributed queries. The internal timeout for all search queries to prevent long running queries. The client request timeout is the maximum cumulative time (in milliseconds) that a distributed search request will wait idly for shard responses.

Options for CQL Solr queries.

The maximum time in milliseconds to wait for all rows to be read from the database during CQL Solr queries.

The default IP address that the HTTP and Solr Admin interface uses to access DSE Search. See Changing Tomcat web server settings.

When left blank, uses the configured hostname of the node. Unlike the listen_address, this value can be set to 0.0.0.0, but you must set the native_transport_broadcast_address to a value other than 0.0.0.0.

Decreasing the memtable space to make room for Solr caches might improve performance. See Changing the stack size and memtable space.

Node routing options.

Node health options are always enabled. Node health is a score-based representation of how healthy a node is to handle search queries. See Collecting node health and indexing status scores.

How frequently statistics update.

The amount of continuous uptime required for the node’s uptime score to advance the node health score from 0 to 1 (full health), assuming there are no recent dropped mutations. The health score is a composite score based on dropped mutations and uptime.

The historic time window over which the rate of dropped mutations affects the node health score.