This issue is for tracking Cassandra software issues of interest to Foundation use-cases.
The system keyspace is distributed over JBOD devices (same as any other), necessitating that an entire node be replaced for the failure of a single device. See CASSANDRA-14793 for proposed solutions.
Proposed deprecation of read_repair_chance
The read_repair_chance/dclocal_read_repair_chance table options are used to probabilistically include all replicas, regardless of consistency level, when conducting a read-repair (for the purposes of repairing a wider set of replicas). Upstream, a proposal has been made to deprecate these options in the 3.11.x branch, and disable them entirely in 4.0 (see upstream issue C13910 and the user mailing thread).
Related to this is CASSANDRA-10726: Read repair inserts should not be blocking, which proposed to make aync read-repairs possible.
Ensure FastThreadLocal.removeAll() is called for all threads
CASSANDRA-9424 is a tracking ticket for issues pertaining to a number of schema improvements (some planned, some completed) impacting the 3.x-4.x series.
The Nodejs driver periodically (30 seconds) issues a query to prevent idle connections from being disconnected. These queries show up in our metrics as RangeSlice queries. We have 32 workers per-host on 24 hosts, each with an open connection to 72 Cassandra instances, or a total of 55296 open connections. Client request rate varies, but is not guaranteed to be high enough to prevent a significant number of these heartbeat queries from being performed (in the RESTBase environment we observe as many of these RangeSlice requests as we do Reads generated by the application).
NODEJS-431 proposes to use an OPTIONS message for hearbeats, similar to that of the Python and Java drivers.