The ScyllaDB team announces the release of ScyllaDB Enterprise 2019.1.8, a production-ready ScyllaDB Enterprise patch release. As always, ScyllaDB Enterprise customers are encouraged to upgrade to ScyllaDB Enterprise 2019.1.8 in coordination with the ScyllaDB support team.
The focus of ScyllaDB Enterprise 2019.1.8 is improving stability and bug fixes to upgrade our high-performance enterprise NoSQL database for real-time big data workloads. More below.
Related Links
- Get ScyllaDB 2019.1.8 (customers only, or 30-day evaluation)
- Upgrade from 2019.1.x to 2019.1.8
- Upgrade from 2018.1.x to 2019.1
- Upgrade from ScyllaDB Open Source 3.0 to ScyllaDB 2019.1
- Submit a ticket
Fixed issues in this release are listed below, with open source references, if present:
- Stability: in some rare cases, SSTable metadata in memory is not correctly evicted, causing memory bloat #4951
- CQL: a restricted column that is not in a select clause returns a wrong value #5708
- Stability: Node shutdown may exit when using encryption in transit #5759, seastar #727
- Performance: scylla doesn’t enforce the use of TSC clocksource #4474
- Stability: wrong hinted handoff logic for detecting a destination node in DN state #4461
- Stability: commit log exception in shutdown #4394
- Stability: potential race condition when creating a table with the same name as a deleted one #4382
- Install: scylla_setup does not present virtio-blk devices correctly on interactive RAID setup #4066
- Stability: malformed replication factor is not blocked in time, causing an error when running DESCRIBE SCHEMA later #3801
- Stability: In rare cases, and under heavy load, for example, during repair, ScyllaDB Enterprise might OOM and exit with an error such as “
compaction_manager - compaction failed: std::bad_alloc (std::bad_alloc)”. #3717 - Stability: possible abort when using reverse queries that read too much data #5804
- Stability: writes inserted into memtable may be interpreted using incorrect schema version on schema ALTER of a counter table #5095
- Stability: possible query failure, crash if the number of columns in a clustering key or partition key is more than 16 #5856
- Stability: When speculative read is configured a write may fail even though enough replicas are alive #6123
- Performance: Allow tweaking of slow repairs due to redundant writes for tables with materialized views
- Stability, hinted_handoff: all nodes in the cluster become overloaded (CPU 100% loaded on all shards) after node finishes the “replace node” procedure
- Monitoring: streaming: Make total_incoming_bytes and total_outgoing_bytes metrics monotonic #5915
