[RELEASE] ScyllaDB Enterprise 2024.1.14

Release Notes
, ,
1

The ScyllaDB team announces ScyllaDB Enterprise 2024.1.14, a bug-fix production-ready patch release for ScyllaDB Enterprise 2024.1 Long Term Support (LTS) Release.

Note there is a later Feature (Short term Support) Release 2024.2.

Related Links

Fixed Issues

The following issues are fixed in this release (with an open-source reference, if available):

Performance Related

  • types: large allocations and stalls while comparing Decimal values #21716
  • The index page cache will now generate fewer disk IOPS if an index read is partially cached. #20935
  • Repair flushes hints and batchlog in order to reduce the amount of work it has to do, but such flushes also generate work, so these flushes are now batched. #20259
  • ScyllaDB tracks whether read requests are waiting for CPU or I/O. In one case, a disk read from the primary index was considered to be waiting on CPU, which reduced concurrency. This is now fixed. #21325

Stability related

  • Metrics created by cql_sg_stats need to be renamed when the corresponding scheduling group is renamed. This was causing a bug which resulted in double metrics, resulting in group0 applier fiber broke due to an exception.
  • Stability: a rare SStable’s clustering key index lookup may yield incorrect position. This could happen in the event of LSA memory compaction in the middle of promoted index entry parsing which moves the cached page and the entry must span file pages, for index larger than 64KB. #20766

Materialized Views Related

  • Until this release, the materialized view flow-control algorithm used a constant delay_limit_us hard-coded to one second, which means that when the size of view-update backlog reached the maximum (10% of memory), we delay every request by an additional second - while smaller amounts of backlog will result in smaller delays.

In this release, the hard-coded default is replaced with a live-updateable configuration parameter, view_flow_control_delay_limit_in_ms, which defaults to 1000ms as before. #18187

  • Add metrics for MV base_writes throttling:

    • throttled_base_writes_total - number of throttled base replica write requests, a throttled write is one whose response was delayed, see mv_flow_control_delay_total
    • last_mv_flow_control_delay - delay (in seconds) added for MV flow control in the last request
    • mv_flow_control_delay_total - total delay (in microseconds) added for MV flow control, to delay the response sent to finished writes, divide this by throttled_base_writes_total to find the average delay

    #20259

Documentation