A Multithreaded Fork of Redis
BSD-3-CLAUSE License
Bot releases are hidden (Show)
KeyDB 6.3.4 Release Notes:
FLASH(Beta):
Dockerfile:
Published by msotheeswaran-sc over 1 year ago
Version 6.3.3 Release Notes
To help accelerate our development efforts for KeyDB, this will be the last release containing support for Centos 7, Ubuntu 16.04, Ubuntu 18.04, Debian 9 and 32-bit builds. For more information click here.
This release contains fixes for 17 issues along with improvements to the KeyDB FLASH feature:
Updates to KeyDB FLASH (Beta):
Published by benschermel over 1 year ago
KeyDB v6.3.2 Release
This release contains Beta level support for KeyDB FLASH, new ASYNC commands, latency improvements and a number of bug fixes.
KeyDB FLASH Support
KeyDB FLASH is included as a Beta feature with this release. Enabling this feature avoids the need to store all data in memory, allowing you to store more data at a lower cost. KeyDB will persist data to the storage medium it is written to avoiding the need for AOF/RDB files. KeyDB uses RocksDB as the persistent storage provider and can be enabled with config storage-provider flash /path/to/flash/output
. Read more at https://docs.keydb.dev/docs/flash/
New ASYNC Commands
In addition to GET/MGET support released with v6.3.0, ASYNC support has been added for the following commands: HGET, HMGET, HKEYS, HVALS, HGETALL, HSCAN and can be enabled with config enable-async-commands yes
Jammy & Bookworm Support
Packaging support for Ubuntu 22.04 (Jammy) and Debian 12 (Bookworm) has been included with this release and will be maintained moving forwards. For details on installation please refer to https://docs.keydb.dev/docs/ppa-deb
Other Improvements & Bug Fixes
Published by benschermel over 2 years ago
KeyDB v6.3.1 Release
This point release contains fixes to bugs related to expires, active-rep, and rdb saving.
The following Issues have been resolved in this release: #419, #422, #428
PRs associated with this release: #426, #429, #431, #433
Please see main commit notes below. For full details please reference PRs
Published by JohnSully over 2 years ago
KeyDB v6.3.0 Release
KeyDB version 6.3.0 is the first open source release to include previously KeyDB Enterprise Features! This release is the culmination of many years of work to move away from KeyDB’s global lock and enable better scaling across cores.
Active Replication PSYNC
Active Replication has been a feature of many KeyDB releases, but always required a full sync while connecting to a new peer. In this release KeyDB now supports partial synchronization to enable fast cluster healing. In addition KeyDB is able to update its replication offset based upon the knowledge of peer nodes, meaning a full sync from one node is enough to permit partial syncs to other nodes within a mesh.
This change greatly reduces the time to add a new node to an active replication cluster. In our testing we’ve seen the time reduced from well over 10 minutes to a minute and a half for a 12 node mesh cluster.
Async Commands
Async commands are commands which can execute without the global lock. This feature must be enabled first in your configuration file by setting “enable-async-commands yes”. When enabling async commands the consistency is modified slightly, in particular writes from other clients may take a configured amount of time to become visible to other clients. This time is configured with the max-snapshot-slip configuration parameter.
The ordering rules with async commands are as follows:
Writes are always totally ordered among clients
Writes are always immediately visible by the client that performed the write
For most applications the slight modification to the consistency model of Active Replication will not be visible. If your application relies on ordering between different clients this feature is disabled by default. In addition a new command called “lfence” is provided for clients that do rely on consistency across clients but are willing to insert fences to assert total ordering at the correct times.
The following commands support async operation:
GET
MGET
Additional read-only commands will get added over time. If a command is of specific interest to you please post an issue to help us prioritize your use case.
Async Rehash
KeyDB relies upon a spinlock to synchronize threads. In prior versions of KeyDB the CPU time consumed while waiting for the lock to be acquired was wasted. KeyDB now has the ability to perform rehash during this time using otherwise wasted CPU time for a more useful purpose. In many cases this can almost completely hide the overhead of rehashing. No configuration is required to enable this functionality, it operates by default.
In Process Background Saving
Historically Redis has used the “fork” system call to create a new process which performed the background save. This made the code easier to follow as the kernel handled the hard task of copy-on-write of memory while background saving was in progress. However the downside to this approach is that it is not possible to accurately estimate the total amount of memory required including background saving.
KeyDB now uses a new “snapshot” system to create snapshots of the database at a specific period and copy-on-write new changes within the process. As a result the maxmemory setting is now a global setting and will include memory used for background save.
For backwards compatibility the semantics of maxmemory are modified slightly during a background save. While a background save is in progress KeyDB will permit memory consumption to exceed maxmemory by up to 20%. This is to simulate the old behavior of background save memory consumption not being counted towards the maxmemory setting while permitting easy calculation of a total upper bound for memory usage.
IStorage Interface
This release does not yet include KeyDB’s FLASH feature based upon RocksDB. However the release does include KeyDB’s IStorage interface which is the backbone of our persistent storage feature. By implementing this interface for your custom storage solution you will enable all KeyDB features.
Thanks To Our Contributors:
Thank you to everyone who contributed to KeyDB with bug reports, design and testing:
Ben Schermel
Firaenix: Bug Report #393 - Crash in sorted sets with long names
Kerog: #401 Error after include *.confg
Gvsafronov: Fedora 35 Compile Failure
Talkabout: Always providing helpful and detailed bug reports, not limited to #378
Inakisoriamrf: #383 crash
Alebcay: #384 macOS build break
Server2245: #379 Install issue on RHEL7
Antiarchitect: #380, and many others
Tchernomax: #352 missing support for systemd
Heng Kuang: Detailed bug reports and design suggestions
Kajaruban Surendran: Detailed performance analysis of async rehash and other features
Paul Chen: Your enthusiasm and willingness to help debug issues has been deeply appreciated.
Special thanks to Huawei Canada Research Team for your detailed and in-depth bug reports and feature requests and design participation.
Thanks to the EQ Alpha Team that made this release possible: Malavan Sotheeswaran, Vivek Saini, Christian Legge, Peter Liang, Ben Schermel, John Sully
Published by christianEQ over 2 years ago
Changes:
Fixed Issues:
#378 #384
Published by VivekSainiEQ almost 3 years ago
This release of KeyDB is at parity with Redis 6.2.6. In addition, the following changes were included:
BITOP SHIFT
and CRON
commands#endif
leading to build errors on some platformsIssues resolved:
#355, #370
Published by MalavanEQAlpha about 3 years ago
Changes:
Fixed Issues:
#323 #325 #276
Published by MalavanEQAlpha about 3 years ago
Changes:
Fixed Issues:
#300 #285 #273 #260 #257 #238
Published by JohnSully about 4 years ago
This release has the following enhancements:
The following issues were fixed:
#234 #236 #233 #207 #229 #231
Published by JohnSully over 4 years ago
New Features!
KEYDB.MEXISTS - return exactly which keys exist in the database not just the count
REPLICAOF REMOVE - Remove specific masters in a multi master setup
multi-master-no-forward configuration option - Reduce network traffic in mesh topology multimaster setups
Redis 6.0.5 feature parity
Fixed Issues:
#194 Bad directive or wrong number of arguments error on 'lazyfree-lazy-user-del no'
#209 Timeout using modules
#210 Databases are not merged on multi-master sync
Published by JohnSully over 4 years ago
This is our first release to fully support all Redis 6.0.4 features, including but not limited to:
KeyDB Has also added the following new features:
In addition we've spent a lot of time focussing on stability. The following bug fixes are resolved:
#150 - Deadlock in ReplicationFeedMonitors
#170 - KeyDB dying via SIGABORT
#180 - crash after setting maxclients via cmd line
#169 - Write performance of a master dropped sharply when a slave is added
In addition untracked issues were resolved:
Published by JohnSully over 4 years ago
Fixes for the following issues:
#155 Crash when a key has multiple sub expires and one is triggered
#154 Failure loading subkey expires
#153 "config get replicaof" returns a corrupt response
#150 Potential deadlock when failing to write to a client
#143 Transancations not always replicated correctly with multi master.
This release also contains additional logging for both deadlocks and replication errors.
Published by JohnSully over 4 years ago
Added new KEYDB.CRON command which will allow lua scripts to be scheduled to run in the future. Support is also added for ring topologies with multi-master.
Bug fixes:
Published by JohnSully over 4 years ago
Fixes an issue where we can crash due to AOF rewrite.
Published by JohnSully almost 5 years ago
Release notes:
Published by JohnSully almost 5 years ago
Published by JohnSully almost 5 years ago
This release fixes a few deadlocks than can hit in some rare situations:
In addition deadlock detection is now added and will bring the server down immediately if one is detected. This will allow faster recovery in the event one is experienced.
Published by JohnSully almost 5 years ago
Major Changes:
For more details see our blog: https://docs.keydb.dev/blog/2019/10/20/blog-post/
Published by JohnSully about 5 years ago
This release fixes an issue where when under load we may incorrectly commit data to database 0 on the replica instead of the selected database.