KeyDB v6.3.0 Release - Feature Summary
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.