The ScyllaDB team announces the release of Scylla Enterprise 2019.1.3, which is a production-ready Scylla Enterprise patch release. As always, Scylla Enterprise customers are encouraged to upgrade to Scylla Enterprise 2019.1.3 in coordination with the Scylla support team.
The focus of Scylla Enterprise 2019.1.3 is improving stability and robustness, by fixing issues and improving security by enabling two new key providers for Encryption at Rest to upgrade our high-performance enterprise NoSQL database for real-time big data workloads. More below.
- Get Scylla 2019.1.3 (customers only, or 30-day evaluation)
- Upgrade from 2019.1.x to 2019.1.3
- Upgrade from 2018.1.x to 2019.1
- Upgrade from Scylla Open Source 3.0 to Scylla 2019.1
- Encryption at Rest
- Submit a ticket
New Providers for Scylla Enterprise Encryption at Rest
We introduced encryption at rest with Scylla 2019.1.1. Scylla Enterprise protects your sensitive data with data-at-rest encryption.
One of the key elements of encryption at rest is storing the encryption keys, and for obvious reasons: if lost, your data become unreadable; if compromised, your data might be exposed.
The encryption key storage options are determined in Scylla by selecting a Key Provider.
Scylla 2019.1.1 only supported with one Key Provider: Local, which allows you to keep keys the file system for each node.
Scylla 2019.1.3 adds two more Key Providers:
- Table provider, allows you to store table keys in Scylla Tables and eliminates the need to copy the table key to each server.
- KMIP provider. KMIP is a standard protocol for exchanging keys in a secure way. With this key provider, you can use any KMIP compatible server to secure Scylla Encryption keys.
More on the new providers here
Fixed issues in this release are listed below, with open source references, if present:
- Stability: Fix of handling of schema alterations and evictions in the cache, which may result in a node crash #5127 #5128 #5134 #5135
- Stability: Fix a bug in cache accounting #5123
- Stability: Fix a bug that can cause streaming to a new node to fail with “Cannot assign requested address” error #4943
- Stability: A race condition in node boot can fail the init process #4709
- Stability: Can not replace a node which is failed in the middle of the boot-up process (same root cause as #4709 above) #4723
- Stability: Perftune.py script fails to start with “name ‘logging’ is not defined” error #4958 #4922
- Stability: Scylla may hang or even segfaults when querying system.size_estimates #4689
- Performance: Range scans run in the wrong service level (workload prioritization) (internal #1052)
- Performance: Wrong priority for View streaming slow down user requests #4615
- Hinted handoff:
- Docker: An issue in command-line options parsing prevents Scylla Docker from starting, reporting “error: too many positional options have been specified on the command line” error #4141
- In-Transit Encryption: Streaming in local DC fails if only inter-DC encryption is enabled #4953