The ScyllaDB team announces ScyllaDB Enterprise 2022.1.11, a bug-fix production-ready ScyllaDB Enterprise patch release for ScyllaDB Enterprise 2022.1.
Note that there is a newer Enterprise LTS release: ScyllaDB Enterprise 2023.1. While we will continue to support 2022.1 LTS, you can get additional features with 2023.1.
Related Links
- Get ScyllaDB Enterprise 2022.1.11 (customers only, or 30-day evaluation)
- Upgrade from 2021.1.x to 2022.1.y
- Upgrade from ScyllaDB Open Source 5.0 to ScyllaDB 2022.1
- Submit a ticket
Below is a list of performance and stability improvements and bug fixes, each with an open-source reference if available:
- Stability: offstrategy compaction races with view building on staging sstables #11882. Off Strategy compaction is triggered after repair and the latter places sstables in the staging subdirectory if view building is required.
- Stability: Scylla should skip mode validation of snapshot files #12010
- Stability: KMIP connector runs an endless loop with more than one failover host, ending with JMX won’t start after enabling KMIP. KMIP server is one of the alternatives for storing keys for Encryption at Rest in ScyllaDB Enterprise.
- Stability: cached_file, used by index caching, will potentially cause a crash after OOM #14814
- Stability: when tables are dropped during a running repair, a repair_tracker run failed: data_dictionary::no_such_column_family #13045
- Stability: Scylla should skip mode validation of snapshot files #12010
- scylla_raid_setup: --online-discard option always enables ‘discard’ #14963
- UX: Warning message does not includes enough details: capped tombstone local_deletion_time warning does not indicate the respective sstable #15015
- Stability: this release adds two new advanced configuration parameters, both related to node “sensitivity” to other node operations. Consult the support team before updating the values.
- nodeops_watchdog_timeout_seconds: Time in seconds after which node operations abort when not hearing from the coordinator. Default 120s. The default watchdog timeout may need to be increased on large clusters if node operations times out early on in their “prepare” phase when remote nodes watchdog timer expires before the node operation coordinator node completes the prepare phase with all nodes, and starts to send heartbeat update messages.
See Node operations may fail if prepare takes longer than heartbeat timeout · Issue #12969 · scylladb/scylladb · GitHub - nodeops_heartbeat_interval_seconds: Period of heartbeat ticks in node operations. Default 10s.
- nodeops_watchdog_timeout_seconds: Time in seconds after which node operations abort when not hearing from the coordinator. Default 120s. The default watchdog timeout may need to be increased on large clusters if node operations times out early on in their “prepare” phase when remote nodes watchdog timer expires before the node operation coordinator node completes the prepare phase with all nodes, and starts to send heartbeat update messages.