snapchat / keydb

A Multithreaded Fork of Redis

KeyDB is now a part of Snap Inc! Check out the announcement here

Release v6.3.0 is here with major improvements as we consolidate our Open Source and Enterprise offerings into a single BSD-3 licensed project. See our roadmap for details.

Want to extend KeyDB with Javascript? Try ModJS

Need Help? Check out our extensive documentation.

KeyDB is on Slack. Click here to learn more and join the KeyDB Community Slack workspace.

What is KeyDB?

KeyDB is a high performance fork of Redis with a focus on multithreading, memory efficiency, and high throughput. In addition to performance improvements, KeyDB offers features such as Active Replication, FLASH Storage and Subkey Expires. KeyDB has a MVCC architecture that allows you to execute queries such as KEYS and SCAN without blocking the database and degrading performance.

KeyDB maintains full compatibility with the Redis protocol, modules, and scripts. This includes the atomicity guarantees for scripts and transactions. Because KeyDB keeps in sync with Redis development KeyDB is a superset of Redis functionality, making KeyDB a drop in replacement for existing Redis deployments.

On the same hardware KeyDB can achieve significantly higher throughput than Redis. Active-Replication simplifies hot-spare failover allowing you to easily distribute writes over replicas and use simple TCP based load balancing/failover. KeyDB's higher performance allows you to do more on less hardware which reduces operation costs and complexity.

The chart below compares several KeyDB and Redis setups, including the latest Redis6 io-threads option, and TLS benchmarks.

See the full benchmark results and setup information here: https://docs.keydb.dev/blog/2020/09/29/blog-post/

Why fork Redis?

KeyDB has a different philosophy on how the codebase should evolve. We feel that ease of use, high performance, and a "batteries included" approach is the best way to create a good user experience. While we have great respect for the Redis maintainers it is our opinion that the Redis approach focuses too much on simplicity of the code base at the expense of complexity for the user. This results in the need for external components and workarounds to solve common problems - resulting in more complexity overall.

Because of this difference of opinion features which are right for KeyDB may not be appropriate for Redis. A fork allows us to explore this new development path and implement features which may never be a part of Redis. KeyDB keeps in sync with upstream Redis changes, and where applicable we upstream bug fixes and changes. It is our hope that the two projects can continue to grow and learn from each other.

Project Support

The KeyDB team maintains this project as part of Snap Inc. KeyDB is used by Snap as part of its caching infrastructure and is fully open sourced. There is no separate commercial product and no paid support options available. We really value collaborating with the open source community and welcome PRs, bug reports, and open discussion. For community support or to get involved further with the project check out our community support options here (slack, forum, meetup, github issues). Our team monitors these channels regularly.

Additional Resources

Try the KeyDB Docker Image

Join us on Slack

Learn more using KeyDB's extensive documentation

See the KeyDB Roadmap to see what's in store

Benchmarking KeyDB

Please note keydb-benchmark and redis-benchmark are currently single threaded and too slow to properly benchmark KeyDB. We recommend using a redis cluster benchmark tool such as memtier. Please ensure your machine has enough cores for both KeyDB and memtier if testing locally. KeyDB expects exclusive use of any cores assigned to it.

New Configuration Options

With new features comes new options. All other configuration options behave as you'd expect. Your existing configuration files should continue to work unchanged.

    server-threads N
    server-thread-affinity [true/false]

The number of threads used to serve requests. This should be related to the number of queues available in your network hardware, not the number of cores on your machine. Because KeyDB uses spinlocks to reduce latency; making this too high will reduce performance. We recommend using 4 here. By default this is set to two.

min-clients-per-thread 50

The minimum number of clients on a thread before KeyDB assigns new connections to a different thread. Tuning this parameter is a tradeoff between locking overhead and distributing the workload over multiple cores

replica-weighting-factor 2

KeyDB will attempt to balance clients across threads evenly; However, replica clients are usually much more expensive than a normal client, and so KeyDB will try to assign fewer clients to threads with a replica. The weighting factor below is intended to help tune this behavior. A replica weighting factor of 2 means we treat a replica as the equivalent of two normal clients. Adjusting this value may improve performance when replication is used. The best weighting is workload specific - e.g. read heavy workloads should set this to 1. Very write heavy workloads may benefit from higher numbers.

active-client-balancing yes

Should KeyDB make active attempts at balancing clients across threads? This can impact performance accepting new clients. By default this is enabled. If disabled there is still a best effort from the kernel to distribute across threads with SO_REUSEPORT but it will not be as fair. By default this is enabled

    active-replica yes

If you are using active-active replication set active-replica option to “yes”. This will enable both instances to accept reads and writes while remaining synced. Click here to see more on active-rep in our docs section. There are also docker examples on docs.

multi-master-no-forward no

Avoid forwarding RREPLAY messages to other masters? WARNING: This setting is dangerous! You must be certain all masters are connected to eachother in a true mesh topology or data loss will occur! This command can be used to reduce multimaster bus traffic

    db-s3-object /path/to/bucket

If you would like KeyDB to dump and load directly to AWS S3 this option specifies the bucket. Using this option with the traditional RDB options will result in KeyDB backing up twice to both locations. If both are specified KeyDB will first attempt to load from the local dump file and if that fails load from S3. This requires the AWS CLI tools to be installed and configured which are used under the hood to transfer the data.

storage-provider flash /path/to/flash

If you would like to use KeyDB FLASH storage, specify the storage medium followed by the directory path on your local SSD volume. Note that this feature is still considered experimental and should be used with discretion. See FLASH Documentation for more details on configuration and setting up your FLASH volume.

Building KeyDB

KeyDB can be compiled and is tested for use on Linux. KeyDB currently relies on SO_REUSEPORT's load balancing behavior which is available only in Linux. When we support marshalling connections across threads we plan to support other operating systems such as FreeBSD.

More on CentOS/Archlinux/Alpine/Debian/Ubuntu dependencies and builds can be found here: https://docs.keydb.dev/docs/build/

Init and clone submodule dependencies:

% git submodule init && git submodule update

Install dependencies:

% sudo apt install build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl-dev uuid-dev libcurl4-openssl-dev libbz2-dev libzstd-dev liblz4-dev libsnappy-dev libssl-dev

Compiling is as simple as:

% make

To build with systemd support, you'll need systemd development libraries (such as libsystemd-dev on Debian/Ubuntu or systemd-devel on CentOS) and run:

% make USE_SYSTEMD=yes

To append a suffix to KeyDB program names, use:

% make PROG_SUFFIX="-alt"

***Note that the following dependencies may be needed: % sudo apt-get install autoconf autotools-dev libnuma-dev libtool

KeyDB by default is built with TLS enabled. To build without TLS support, use:

% make BUILD_TLS=no

Running the tests with TLS enabled (you will need tcl-tls installed):

% ./utils/gen-test-certs.sh
% ./runtest --tls

To build with KeyDB FLASH support, use:

% make ENABLE_FLASH=yes

***Note that the KeyDB FLASH feature is considered experimental (beta) and should used with discretion

Fixing build problems with dependencies or cached build options

KeyDB has some dependencies which are included in the deps directory. make does not automatically rebuild dependencies even if something in the source code of dependencies changes.

When you update the source code with git pull or when code inside the dependencies tree is modified in any other way, make sure to use the following command in order to really clean everything and rebuild from scratch:

make distclean

This will clean: jemalloc, lua, hiredis, linenoise.

Also if you force certain build options like 32bit target, no C compiler optimizations (for debugging purposes), and other similar build time options, those options are cached indefinitely until you issue a make distclean command.

Fixing problems building 32 bit binaries

If after building KeyDB with a 32 bit target you need to rebuild it with a 64 bit target, or the other way around, you need to perform a make distclean in the root directory of the KeyDB distribution.

In case of build errors when trying to build a 32 bit binary of KeyDB, try the following steps:

• Install the package libc6-dev-i386 (also try g++-multilib).
• Try using the following command line instead of make 32bit: make CFLAGS="-m32 -march=native" LDFLAGS="-m32"

Allocator

Selecting a non-default memory allocator when building KeyDB is done by setting the MALLOC environment variable. KeyDB is compiled and linked against libc malloc by default, with the exception of jemalloc being the default on Linux systems. This default was picked because jemalloc has proven to have fewer fragmentation problems than libc malloc.

To force compiling against libc malloc, use:

% make MALLOC=libc

To compile against jemalloc on Mac OS X systems, use:

% make MALLOC=jemalloc

Monotonic clock

By default, KeyDB will build using the POSIX clock_gettime function as the monotonic clock source. On most modern systems, the internal processor clock can be used to improve performance. Cautions can be found here: http://oliveryang.net/2015/09/pitfalls-of-TSC-usage/

To build with support for the processor's internal instruction clock, use:

% make CFLAGS="-DUSE_PROCESSOR_CLOCK"

Verbose build

KeyDB will build with a user friendly colorized output by default. If you want to see a more verbose output, use the following:

% make V=1

Running KeyDB

To run KeyDB with the default configuration, just type:

% cd src
% ./keydb-server

If you want to provide your keydb.conf, you have to run it using an additional parameter (the path of the configuration file):

% cd src
% ./keydb-server /path/to/keydb.conf

It is possible to alter the KeyDB configuration by passing parameters directly as options using the command line. Examples:

% ./keydb-server --port 9999 --replicaof 127.0.0.1 6379
% ./keydb-server /etc/keydb/6379.conf --loglevel debug

All the options in keydb.conf are also supported as options using the command line, with exactly the same name.

Running KeyDB with TLS:

Please consult the TLS.md file for more information on how to use KeyDB with TLS.

Playing with KeyDB

You can use keydb-cli to play with KeyDB. Start a keydb-server instance, then in another terminal try the following:

% cd src
% ./keydb-cli
keydb> ping
PONG
keydb> set foo bar
OK
keydb> get foo
"bar"
keydb> incr mycounter
(integer) 1
keydb> incr mycounter
(integer) 2
keydb>

You can find the list of all the available commands at https://docs.keydb.dev/docs/commands/

Installing KeyDB

In order to install KeyDB binaries into /usr/local/bin, just use:

% make install

You can use make PREFIX=/some/other/directory install if you wish to use a different destination.

Make install will just install binaries in your system, but will not configure init scripts and configuration files in the appropriate place. This is not needed if you just want to play a bit with KeyDB, but if you are installing it the proper way for a production system, we have a script that does this for Ubuntu and Debian systems:

% cd utils
% ./install_server.sh

Note: install_server.sh will not work on Mac OSX; it is built for Linux only.

The script will ask you a few questions and will setup everything you need to run KeyDB properly as a background daemon that will start again on system reboots.

You'll be able to stop and start KeyDB using the script named /etc/init.d/keydb_<portnumber>, for instance /etc/init.d/keydb_6379.

Multithreading Architecture

KeyDB works by running the normal Redis event loop on multiple threads. Network IO, and query parsing are done concurrently. Each connection is assigned a thread on accept(). Access to the core hash table is guarded by spinlock. Because the hashtable access is extremely fast this lock has low contention. Transactions hold the lock for the duration of the EXEC command. Modules work in concert with the GIL which is only acquired when all server threads are paused. This maintains the atomicity guarantees modules expect.

Unlike most databases the core data structure is the fastest part of the system. Most of the query time comes from parsing the REPL protocol and copying data to/from the network.

Code contributions

Note: by contributing code to the KeyDB project in any form, including sending a pull request via Github, a code fragment or patch via private email or public discussion groups, you agree to release your code under the terms of the BSD license that you can find in the COPYING file included in the KeyDB source distribution.

Please see the CONTRIBUTING file in this source distribution for more information.

keydb's Issues

Getting timeout when adding document to Redisearch

Hi,
I'm trying to use redisearch with keydb. Afaik, keydb supports modules. I can create indices but I get timeout when adding document. You can reproduce this issue with these codes:

root@keydb-0:/data# keydb-cli
127.0.0.1:6379> FT.CREATE idx SCHEMA id NUMERIC SORTABLE name TEXT SORTABLE
OK
127.0.0.1:6379> FT.ADD idx 1 1.0 FIELDS id 1 name 'NameTest'

Section addressing non-serialiazability of a multithreaded redis

A significant reason is great is that scripts and MULTI-EXEC commands are isolated from other clients making it easy to reason about transactions. This comes from the single threaded nature of redis. I didn't find a section in your README addressing the concern that KeyDB would allow 2 transactions to run concurrently.

More test results

Ubuntu 18.04 LTS - Kernel v5.1.9

Providing only the relevant part:

[34/52 done]: unit/type/list-3 (48 seconds)
Testing unit/wait
[err]: FLUSHDB ASYNC can reclaim memory in background in tests/unit/lazyfree.tcl
Expected condition '$peak_mem > $orig_mem+1000000' to be true (13838096 > 13734512+1000000)

ARM Support

Arm currently compiles, but crashes with multiple threads. Our fastlock implementation assumes X86's very strong memory model. This needs to be updated for ARM.

CRDT based synchronization strategy - feature

This ticket is to track the feature request.

• Enable CRDT based synchronization strategy feature in keysdb.

A question about KEYS variable in lua scripts

As I understand it, in mainline redis the difference between KEYS and ARGV is that Redis will make sure that the KEYS values exist on the current slot in a clustered environment and will otherwise fail with CROSSSLOT if one of them does not.

This limits the ability to write scripts that perform dynamic key composition (where a key is built up in lua-land on the instance) in a clustered environment, making the two features mutually exclusive - which is unfortunate.

However, with KeyDB the clustering/replication properties have changed a bit. Is the KEYS/dynamic key generation limitation still applicable in KeyDB? Or can I safely use dynamic keys in a clustered environment?

I understand that KeyDB provides both KEYS and ARGV for compatibility but I'm interested in whether or not dynamic key referencing in a clustered environment will work as intended or if it still follows the mainline Redis limitations.

Thanks John! :)

EDIT: I just read through most of the HN thread and realize now that I wouldn't even want a cluster mode with KeyDB (thanks!). I'm still interested in the answer, purely for academic purposes :)

Unexpected reply to PSYNC from master: -NOAUTH

I am trying to add a replica slave from host2:6380 to my master on host1:6379 and added
masterauth into the appropriate keydb-slave.conf.
The master is running with an identical requirepass definition.
However as the slave tries to connect to master it fails with:
Unexpected reply to PSYNC from master: -NOAUTH Authentication required.

Would someone know what I am doing wrong? Thx

HGETALL returns NIL, Redis returns EMPTY SET

When you run HGETALL against a key that doesnt exist, KeyDB returns a NIL response. Redis returns (empty list or set). This breaks compatibility with some libraries (StackExchange.Redis)

SETUP

docker run -it -p 6391:6379 eqalpha/keydb:latest
docker run -it -p 6390:6379 redis:latest

Test

will@45K9VT2:/mnt/c/Users/wdavis$ redis-cli -p 6390 HGETALL test
(empty list or set)
will@45K9VT2:/mnt/c/Users/wdavis$ redis-cli -p 6391 HGETALL test
(nil)
will@45K9VT2:/mnt/c/Users/wdavis$

Build Errors

I hope I am not wasting your time, because I intend not to.
This is the results of the Redis tests on my Ubuntu 16.04 LTS:

!!! WARNING The following tests failed:

*** [err]: Command Filter REDISMODULE_CMDFILTER_NOSELF works as expected in tests/modules/commandfilter.tcl
Expected '' to be equal to '{set mykey @log}'
*** [err]: SLAVE can reload "lua" AUX RDB fields of duplicated scripts in tests/integration/replication-3.tcl
Replication not started.

If this is the expected result, please ignore this and close the thread.

MALLOC =memkind compile related issues

I created successfully a rpm with MALLOC=jemalloc and jemalloc-devel system libraries, on CentOS 7.6 and GCC 5.3.1. Everything fails when I try to use either deps/memkind, or memkind-devel-1.7.0 system libraries.

%global modules_abi     1
%global source_name     KeyDB

Name:                   keydb
Version:                0.9.4
Release:                1%{?dist}
Summary:                Multithreaded fork of Redis
License:                BSD
URL:                    https://github.com/JohnSully/KeyDB
Source0:                %{url}/archive/v%{version}.tar.gz#/%{source_name}-%{version}.tar.gz
Source1:                %{name}.logrotate
Source2:                %{name}.service
Source3:                %{name}-sentinel.service
Source4:                %{name}.limit
Source5:                %{name}.tmpfiles
Source6:                %{name}.shutdown
Patch:                  0002-install-redis-check-rdb-as-a-symlink-instead-of-dupl.patch
ExclusiveArch:          x86_64
BuildRequires:          gcc >= 5.3.0
BuildRequires:          jemalloc-devel
BuildRequires:          libuuid-devel
BuildRequires:          memkind-devel
BuildRequires:          nasm
BuildRequires:          redis-rpm-macros
BuildRequires:          systemd
BuildRequires:          tcl-devel
Requires:               gawk
Requires:               logrotate
Provides:               bundled(hiredis)
Provides:               bundled(linenoise)
Provides:               bundled(lua-libs)
Provides:               bundled(lzf)
Provides:               %{name}(modules_abi)%{?_isa} = %{modules_abi}
Conflicts:              redis
%{?%systemd_requires}


%prep
%autosetup -n %{source_name}-%{version} -p1
%{__rm} -rf deps/jemalloc
%{__rm} -rf deps/memkind
%{__sed} -i -e '/cd jemalloc && /d' deps/Makefile
%{__sed} -i -e '/cd memkind && /d' deps/Makefile
%{__sed} -i -e 's|../deps/jemalloc/lib/libjemalloc.a|-ljemalloc -ldl|g' src/Makefile
%{__sed} -i -e 's|-I../deps/jemalloc.*|-DJEMALLOC_NO_DEMANGLE -I%{_includedir}/jemalloc|g' src/Makefile
%{__sed} -i -e 's|../deps/memkind/src/.libs/libmemkind.a|-lmemkind|g' src/Makefile
%{__sed} -i -e 's|-I../deps/memkind.*|-I%{_includedir}/memkind|g' src/Makefile
%{__sed} -i -e 's|redis|%{name}|g' redis.conf
%{__sed} -i -e 's|%{name}\.io|redis.io|g' redis.conf
%{__sed} -i -e 's|^logfile .*$|logfile %{_localstatedir}/log/%{name}/%{name}.log|g' redis.conf
%{__sed} -i -e '$ alogfile %{_localstatedir}/log/%{name}/sentinel.log' sentinel.conf
%{__sed} -i -e 's|^dir .*$|dir %{_sharedstatedir}/%{name}|g' redis.conf
api=$(sed -n -e 's/#define REDISMODULE_APIVER_[0-9][0-9]* //p' src/redismodule.h)
if [ "$api" != "%{modules_abi}" ]; then
    : Error: Upstream API version is now ${api}, expecting %%{modules_abi}.
    : Update the modules_abi macro, the rpmmacros file, and rebuild.
    exit 1
fi


%build
%make_build CFLAGS+="%{optflags} -fPIC" LDFLAGS="%{__global_ldflags}" \
    MALLOC=memkind PREFIX=%{buildroot}%{_prefix} all

    CC storage.o
storage.cpp: In function 'int forkFile()':
storage.cpp:124:35: error: 'memkind_tmpfile' was not declared in this scope
     memkind_tmpfile(PMEM_DIR, &fdT);
                                   ^
storage.cpp:125:46: error: 'memkind_fd' was not declared in this scope
     if (ioctl(fdT, FICLONE, memkind_fd(mkdisk)) == -1)
                                              ^
storage.cpp: In function 'void storage_init(const char*, size_t)':
storage.cpp:177:44: error: 'memkind_fd' was not declared in this scope
         posix_fallocate64(memkind_fd(mkdisk), 0, cbFileReserve);
                                            ^
storage.cpp: In function 'size_t salloc_usable_size(void*)':
storage.cpp:214:60: error: 'memkind_malloc_usable_size' was not declared in this scope
     return memkind_malloc_usable_size(kindFromPtr(ptr), ptr);
                                                            ^
storage.cpp: In function 'void handle_postfork_child()':
storage.cpp:269:39: error: 'memkind_fd' was not declared in this scope
     int fdOriginal = memkind_fd(mkdisk);
                                       ^
storage.cpp:270:39: error: 'memkind_pmem_remapfd' was not declared in this scope
     memkind_pmem_remapfd(mkdisk, fdNew);
                                       ^
make[1]: *** [storage.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: Leaving directory `/builddir/build/BUILD/KeyDB-0.9.4/src'
make: *** [all] Error 2

I'm only interested to build using system libraries. I tried building with the /deps but it failed also.

Feature Request, Expire members of a set

Hi,

One of the much requested features, to expire individual members of a set, is unlikely to get implemented in Redis, hoping KeyDb can take to improve it

redis/redis#135

[Q] keys scan command

REDIS warning..
..........................................
When the number of keys in redis (use DBSIZE to know the count) is less, this method can be used but when redis size grows, using keys cmd is extremely dangerous for performance and highly discouraged in production environment since redis is single threaded, keys cmd will block all other operations on redis and all the clients will have to wait for its completion.
..........................................

Is KeyDB subject to the same constraints or not ?

RREPLAY Command doesn't execute with permissions of the client

The root cause is the fake user we create to execute commands in RREPLAY doesn't have the authentication information of the client executing the RREPLAY command. This may cause commands to fail due to permission issues.

Add test for replicaof config

This runs the createMaster function before databases are allocated and has been broken more than once. Current tests only create replicas via command after boot has completed and so do not validate this scenario.

The test infra needs to be modified slightly to support this.

The latest example of this is issue #58

Remove ifdef hack for deprecated malloc+family

Some users are reporting that these deprecated prototypes fail to compile because the exception specifier doesn't match. The hack removes the deprecated flags for C++ builds (C does not have exception specifiers).

These should still flag an error in C++ so this issue tracks reenabled the deprecated flag for C++.

Hack checked in here: a9e525c

Error when make

just use make

make[3]: Leaving directory '/home/atn4517/KeyDB-0.9.2/deps/jemalloc'
make[2]: Leaving directory '/home/atn4517/KeyDB-0.9.2/deps'
    CC adlist.o
    CC quicklist.o
    CC ae.o
    CC anet.o
    CC dict.o
    CC server.o
In file included from server.cpp:31:0:
server.h:2331:68: error: declaration of ‘void* calloc(size_t, size_t)’ has a different exception specifier
 void *calloc(size_t count, size_t size) __attribute__ ((deprecated));
                                                                    ^
In file included from server.h:42:0,
                 from server.cpp:31:
/usr/include/stdlib.h:468:14: error: from previous declaration ‘void* calloc(size_t, size_t) throw ()’
 extern void *calloc (size_t __nmemb, size_t __size)
              ^
In file included from server.cpp:31:0:
server.h:2332:49: error: declaration of ‘void free(void*)’ has a different exception specifier
 void free(void *ptr) __attribute__ ((deprecated));
                                                 ^
In file included from server.h:42:0,
                 from server.cpp:31:
/usr/include/stdlib.h:483:13: error: from previous declaration ‘void free(void*) throw ()’
 extern void free (void *__ptr) __THROW;
             ^
In file included from server.cpp:31:0:
server.h:2333:54: error: declaration of ‘void* malloc(size_t)’ has a different exception specifier
 void *malloc(size_t size) __attribute__ ((deprecated));
                                                      ^
In file included from server.h:42:0,
                 from server.cpp:31:
/usr/include/stdlib.h:466:14: error: from previous declaration ‘void* malloc(size_t) throw ()’
 extern void *malloc (size_t __size) __THROW __attribute_malloc__ __wur;
              ^
In file included from server.cpp:31:0:
server.h:2334:66: error: declaration of ‘void* realloc(void*, size_t)’ has a different exception specifier
 void *realloc(void *ptr, size_t size) __attribute__ ((deprecated));
                                                                  ^
In file included from server.h:42:0,
                 from server.cpp:31:
/usr/include/stdlib.h:480:14: error: from previous declaration ‘void* realloc(void*, size_t) throw ()’
 extern void *realloc (void *__ptr, size_t __size)
              ^
Makefile:278: recipe for target 'server.o' failed
make[1]: *** [server.o] Error 1
make[1]: Leaving directory '/home/user/KeyDB-0.9.2/src'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2

Addition of a build system generator

I suggest to reuse a higher level build system than your current make script so that powerful checks for software features will become easier.

• CMake
• Autotools

Setup CI Servers

Lots of build errors on specific platforms. This tracks CI on Debian, Ubuntu, and Fedora.

Failed Tests

I am using Ubuntu 18.04 LTS and running make tests throws the followings:

!!! WARNING The following tests failed:
*** [err]: Server is able to generate a stack trace on selected systems in tests/integration/logging.tcl
expected stack trace not found into log file
*** [err]: PSYNC2: cluster is consistent after load (x = 52143) in tests/integration/psync2.tcl
Instance #1 x variable is inconsistent

Should I be concerned?

reserved identifier violation

I would like to point out that identifiers like “__AE_H__” and “__RDB_H” do not fit to the expected naming convention of the C++ language standard.
Would you like to adjust your selection for unique names?

Active Replicas Report Themselves as Slaves in INFO command

This is just an informational bug in the output of the command.

Do you need GUI?

Hi, do you need gui for KeyDB?

Completion of error handling

Would you like to add more error handling for return values from functions like the following?

• pthread_cond_init ⇒ bioInit
• pthread_mutex_init ⇒ initServerConfig

some clarifications regarding replication

Hello,

I need few clarifications regarding the active-active replication and the performance impact.

1. The replication is async ?

For example I have 2 datacenters, in each datacenter for each shard I'm planning to add 2 nodes in active- active replication.

Each shard in DC1 will have an associated shard in DC2 as well with the same number of nodes.

So in the end each redis node from a shard will have 3 replicas (1 in the same dc and 2 in the other dc).

In case the replication is sync the performance impact will be high so this is my biggest concern in this moment comparing with
the https://github.com/Netflix/dynomite where the replication is async.

2. How fail-over works ?

Let's suppose one node goes down. While is down the clients will send the read/writes to the other replicas.
After some time the node is fixed and started back. The node will accept connections from clients only after it's in sync with the other replicas ?

Because otherwise the clients can start connecting to it and send requests to keys that were not already propagated from replicas

Kind regards,
Silviu

Is it possible to use that software to build your own DBaaS solution or license it on-prem basis?

Release 5 sieze-up, followed by crash on replica promotion

We saw a KeyDB server built from the RELEASE_5 branch become completely unresponsive yesterday. Our systems responded by promoting a replica which crashed immediately when receiving SLAVEOF NO ONE

Unfortunately I don't have many details about the master to share, other than noting that the overall system was showing nominal behavior and load, with log output stopping around 12:19 UTC. The replica logs below start at about that time when the master connection is dropped, and our system attempts a promotion at 12:24 UTC.

Jul 14 12:19:55 keydb-server[2905]: 2905:S 14 Jul 2019 12:19:55.834 # MASTER timeout: no data nor PING received...
Jul 14 12:19:55 keydb-server[2905]: 2905:S 14 Jul 2019 12:19:55.834 # Connection with master lost.
Jul 14 12:19:55 keydb-server[2905]: 2905:S 14 Jul 2019 12:19:55.834 * Caching the disconnected master state.
Jul 14 12:19:55 keydb-server[2905]: 2905:S 14 Jul 2019 12:19:55.834 * Connecting to MASTER xxxxx
Jul 14 12:19:55 keydb-server[2905]: 2905:S 14 Jul 2019 12:19:55.836 * MASTER <-> REPLICA sync started
Jul 14 12:22:05 keydb-server[2905]: 2905:S 14 Jul 2019 12:22:05.349 # Error condition on socket for SYNC: Connection timed out
Jul 14 12:22:06 keydb-server[2905]: 2905:S 14 Jul 2019 12:22:06.073 * Connecting to MASTER xxxxx
Jul 14 12:22:06 keydb-server[2905]: 2905:S 14 Jul 2019 12:22:06.077 * MASTER <-> REPLICA sync started
Jul 14 12:24:16 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:16.421 # Error condition on socket for SYNC: Connection timed out
Jul 14 12:24:17 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:17.316 * Connecting to MASTER xxxxx
Jul 14 12:24:17 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:17.320 * MASTER <-> REPLICA sync started
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 # Setting secondary replication ID to 9b8fd931f161c8be497aa79b23823c188394905d, valid up to offset: 4659745187. New replication ID is 78b24b65287543c6c19c9e3ba964996d2881558c
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 * Discarding previously cached master state.
Jul 14 12:24:48 keydb-server[2905]: AE_ASSER FAILURE
Jul 14 12:24:48 keydb-server[2905]: === KEYDB BUG REPORT START: Cut & paste starting from here ===
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 # KeyDB 5.0.0 crashed by signal: 11
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 # Crashed running the instruction at: 0x432eee
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 # Accessing address: (nil)
Jul 14 12:24:48 keydb-server[2905]: 2905:S 14 Jul 2019 12:24:48.290 # Failed assertion: <no assertion failed> (<no file>:0)
Jul 14 12:24:48 keydb-server[2905]: ------ STACK TRACE ------
Jul 14 12:24:48 keydb-server[2905]: EIP:
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(aeDeleteFileEvent+0x3e) [0x432eee]
Jul 14 12:24:48 keydb-server[2905]: Backtrace:
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(logStackTrace(ucontext_t*)+0x39) [0x4851a9]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(sigsegvHandler(int, siginfo_t*, void*)+0xa4) [0x485824]
Jul 14 12:24:48 keydb-server[2905]: /lib64/libpthread.so.0(+0x121f0) [0x7f964976c1f0]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(aeDeleteFileEvent+0x3e) [0x432eee]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(undoConnectWithMaster(redisMaster*)+0x26) [0x457596]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(cancelReplicationHandshake(redisMaster*)+0x25) [0x457635]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(replicationUnsetMaster(redisMaster*)+0x97) [0x457ef7]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(replicaofCommand(client*)+0x17c) [0x45886c]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(call(client*, int)+0xbd) [0x43a6dd]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(execCommand(client*)+0xc7) [0x481ff7]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(call(client*, int)+0xbd) [0x43a6dd]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(processCommand(client*, int)+0x789) [0x43ebc9]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(processCommandAndResetClient(client*, int)+0x21) [0x447391]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(processInputBuffer(client*, int)+0x7a) [0x44bbba]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(readQueryFromClient(aeEventLoop*, int, void*, int)+0x338) [0x44c138]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(ProcessEventCore+0xe9) [0x433409]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(aeProcessEvents+0x14d) [0x43369d]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(aeMain+0x2d) [0x433a0d]
Jul 14 12:24:48 keydb-server[2905]: /usr/local/bin/keydb-server *:11042(workerThreadMain(void*)+0x90) [0x437aa0]
Jul 14 12:24:48 keydb-server[2905]: /lib64/libpthread.so.0(+0x754b) [0x7f964976154b]
Jul 14 12:24:48 keydb-server[2905]: /lib64/libc.so.6(clone+0x3f) [0x7f96494992ff]

Client details for the replica:

Jul 14 12:24:48 keydb-server[2905]: ------ CLIENT LIST OUTPUT ------
Jul 14 12:24:48 keydb-server[2905]: id=13 addr=172.16.101.10:44516 fd=98 name=redisgreen-monitoring age=197244 idle=24 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=slowlog
Jul 14 12:24:48 keydb-server[2905]: id=16 addr=172.16.101.11:57666 fd=96 name= age=0 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
Jul 14 12:24:48 keydb-server[2905]: id=17 addr=172.16.101.11:57668 fd=97 name=redisgreen age=0 idle=0 flags=x db=0 sub=0 psub=0 multi=2 qbuf=123 qbuf-free=32645 obl=27 oll=0 omem=0 events=r cmd=exec
Jul 14 12:24:48 keydb-server[2905]: ------ CURRENT CLIENT INFO ------
Jul 14 12:24:48 keydb-server[2905]: id=17 addr=172.16.101.11:57668 fd=97 name=redisgreen age=0 idle=0 flags=x db=0 sub=0 psub=0 multi=2 qbuf=123 qbuf-free=32645 obl=27 oll=0 omem=0 events=r cmd=exec
Jul 14 12:24:48 keydb-server[2905]: argv[0]: 'slaveof'
Jul 14 12:24:48 keydb-server[2905]: argv[1]: 'no'
Jul 14 12:24:48 keydb-server[2905]: argv[2]: 'one'

How to configure a cluster with several KeyDBs ?

I can't find documentation about use KeyDB as a cluster

keydb crashed again, again

I'm using active-active replication in docker environments

docker -v
Docker version 18.09.6, build 481bc77156
uname -a (CENTOS 7)
Linux ocean-02 3.10.0-957.12.2.el7.x86_64 #1 SMP Tue May 14 21:24:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

ERROR MESSAGE:

...........
what(): Operation not permitted
Aborted
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
Aborted
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
Aborted
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
Aborted
terminate called after throwing an instance of 'std::system_error'
what(): Operation not permitted
Aborted
...........

multi-master installation steps.

Hello,

We are trying out the evaluation for multi master setup where keydb would be installed in 2 different zones having multi master mode enabled.

I went through this link provided in the wiki https://github.com/JohnSully/KeyDB/wiki/Multimaster-Support but i was unable to figure out the complete configurations required.

Only parameter which i found is multi-master yes in the configuration, i am not sure how would i configure other master to which the sync would happen.

Could you please help me on this.

Thanks.
Shiva

Memory accumulates when running long lua scripts

The following script repeatedly sets a key to different values. Memory grows quickly and excessively as the script is run (over many GB). If the script is able to run to completion the memory is freed.

Script:
for i = 1, 10000000000, 1 do
redis.call("SET", "ZzZ_MYKEYZzZ"..i.."key", i)
end

Repro:
./keydb-cli --eval /tmp/bench.lua

This behavior is particularly bad when FLASH backing is used as it leads to write amplification.

Mixing multiple masters and Active Replication causes reconnection loop

This issue tracks the following two issues:

Reconnection loops
Command loops

Its caused by the feedback loop enabled by Active Replication. These issues are resolved for single masters but reappear with multiple masters and more complex topologies.

build error on centos 7

keydb_v0.9.5, i am getting error with centos 7

cc: error: unrecognized command line option ‘-std=c++14’
make[1]: *** [ae.o] Error 1
make[1]: Leaving directory `/home/hadn/dynomite/KeyDB-0.9.5/src'
make: *** [all] Error 2

[hadn@vsftpd src]$ uname -a
Linux vsftpd 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 29 14:49:43 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

crash from failed assertion in networking.cpp

Hi there, in case it's useful here's a crash from a KeyDB instance built off the RELEASE_5 branch last week, using 6 threads, virtual network interface has 8 queues. I can provide more details and/or sanitize the INFO/CLIENT payloads if it'd be helpful.

Jul 14 03:20:04 keydb-server[2881]: === KEYDB BUG REPORT START: Cut & paste starting from here ===
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # === ASSERTION FAILED CLIENT CONTEXT ===
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # client->flags = 2097152
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # client->fd = 425
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # client->argc = 2
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # client->argv[0] = ">" (refcount: 2)
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # client->argv[1] = "queue:keydb2" (refcount: 1)
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # === ASSERTION FAILED ===
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # ==> networking.cpp:2633 'c->cmd != NULL' is not true
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # (forcing SIGSEGV to print the bug report.)
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # KeyDB 5.0.0 crashed by signal: 11
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # Crashed running the instruction at: 0x482738
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # Accessing address: 0xffffffffffffffff
Jul 14 03:20:04 keydb-server[2881]: 2881:M 14 Jul 2019 03:20:04.799 # Failed assertion: c->cmd != NULL (networking.cpp:2633)
Jul 14 03:20:04 keydb-server[2881]: ------ STACK TRACE ------
Jul 14 03:20:04 keydb-server[2881]: EIP:
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(_serverAssert+0x78) [0x482738]
Jul 14 03:20:04 keydb-server[2881]: Backtrace:
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(logStackTrace(ucontext_t*)+0x39) [0x4851a9]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(sigsegvHandler(int, siginfo_t*, void*)+0xa4) [0x485824]
Jul 14 03:20:04 keydb-server[2881]: /lib64/libpthread.so.0(+0x121f0) [0x7fc293da61f0]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(_serverAssert+0x78) [0x482738]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(rewriteClientCommandVector(client*, int, ...)+0x120) [0x447df0]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(blockingPopGenericCommand(client*, int)+0x1db) [0x4666bb]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(call(client*, int)+0xbd) [0x43a6dd]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(processCommand(client*, int)+0x789) [0x43ebc9]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(processCommandAndResetClient(client*, int)+0x21) [0x447391]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(processInputBuffer(client*, int)+0x7a) [0x44bbba]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(readQueryFromClient(aeEventLoop*, int, void*, int)+0x338) [0x44c138]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(ProcessEventCore+0xe9) [0x433409]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(aeProcessEvents+0x14d) [0x43369d]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(aeMain+0x2d) [0x433a0d]
Jul 14 03:20:04 keydb-server[2881]: /usr/local/bin/keydb-server *:11042(workerThreadMain(void*)+0x90) [0x437aa0]
Jul 14 03:20:04 keydb-server[2881]: /lib64/libpthread.so.0(+0x754b) [0x7fc293d9b54b]
Jul 14 03:20:04 keydb-server[2881]: /lib64/libc.so.6(clone+0x3f) [0x7fc293ad32ff]

Does KeyDB support WAIT command in active-active to wait for data propagation?

x.y.z.d:6379> wait 1 1
(error) ERR WAIT cannot be used with replica instances. Please also note that since Redis 4.0 if a replica is configured to be writable (which is not the default) writes to replicas are just local and are not propagated.

v0.9.6 tag syntax

The 0.9.6 tag dropped the 'v' prefix (and is thus harder to notice in the list) than v0.9.5, v0.9.4, etc. Looks accidental?

Replication information not available, can't generate the RDB file right now

We are running a two master setup in active-active mode, both instances crashed a few hours ago after running fine for about a week and now I am trying to get them back in sync. I started one of the master's and then proceeded to start the second master after the AOF file from the first master was loaded (I did remove the AOF file from the second master in order to get a clean state). After several attempts with the second master to sync with the first master I am now getting this error: (which loops indefinitely)

1:S 14 Jul 2019 19:52:41.104 * MASTER <-> REPLICA sync started
1:S 14 Jul 2019 19:52:41.104 * Non blocking connect for SYNC fired the event.
1:S 14 Jul 2019 19:52:41.105 * Master replied to PING, replication can continue...
1:S 14 Jul 2019 19:52:41.106 * Partial resynchronization not possible (no cached master)
1:S 14 Jul 2019 19:52:41.106 * Master does not support PSYNC or is in error state (reply: -ERR BGSAVE failed, replication can't continue)
1:S 14 Jul 2019 19:52:41.106 * Retrying with SYNC...
1:S 14 Jul 2019 19:52:41.106 # I/O error reading bulk count from MASTER: Resource temporarily unavailable
1:S 14 Jul 2019 19:52:41.662 * Replica XX.XX.XX.XXX:6380 asks for synchronization
1:S 14 Jul 2019 19:52:41.662 * Full resync requested by replica XX.XX.XX.XXX:6380
1:S 14 Jul 2019 19:52:41.662 * Starting BGSAVE for SYNC with target: disk
1:S 14 Jul 2019 19:52:41.662 # BGSAVE for replication: replication information not available, can't generate the RDB file right now. Try later.
1:S 14 Jul 2019 19:52:41.662 # BGSAVE for replication failed
...
BGSAVE for replication: replication information not available, can't generate the RDB file right now. Try later.

What is the preferred approach to recovering from a crash in an active-active replication setup?

Segfault on databases > 16

Thank you for your work on KeyDB!

This problem is reproducible on OSX and Linux - configure with databases 17 (or any number higher than 16) and keydb-server will segfault on startup with (trace from Amazon Linux 2):

=== KEYDB BUG REPORT START: Cut & paste starting from here ===
2841:M 12 Jul 2019 05:51:37.727 # KeyDB 5.0.0 crashed by signal: 11
2841:M 12 Jul 2019 05:51:37.727 # Crashed running the instruction at: 0x43b081
2841:M 12 Jul 2019 05:51:37.727 # Accessing address: 0x48
2841:M 12 Jul 2019 05:51:37.727 # Failed assertion: <no assertion failed> (<no file>:0)

------ STACK TRACE ------
EIP:
./keydb-server *:6379(serverCron(aeEventLoop*, long long, void*)+0x1a1) [0x43b081]

Backtrace:
./keydb-server *:6379(logStackTrace(ucontext_t*)+0x39) [0x4851a9]
./keydb-server *:6379(sigsegvHandler(int, siginfo_t*, void*)+0xa4) [0x485824]
/lib64/libpthread.so.0(+0x121f0) [0x7fe1f24981f0]
./keydb-server *:6379(serverCron(aeEventLoop*, long long, void*)+0x1a1) [0x43b081]
./keydb-server *:6379(aeProcessEvents+0x223) [0x433773]
./keydb-server *:6379(aeMain+0x2d) [0x433a0d]
./keydb-server *:6379(workerThreadMain(void*)+0x90) [0x437aa0]
/lib64/libpthread.so.0(+0x754b) [0x7fe1f248d54b]
/lib64/libc.so.6(clone+0x3f) [0x7fe1f21c52ff]

------ INFO OUTPUT ------
Segmentation fault

zrangebyscore return (nil)

simple redis (redis:alpine)

redis-cli
127.0.0.1:6379> ZADD myzset 1 "one"
(integer) 1
127.0.0.1:6379> ZADD myzset 2 "two"
(integer) 1
127.0.0.1:6379> ZADD myzset 3 "three"
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE myzset -inf +inf
1) "one"
2) "two"
3) "three"
127.0.0.1:6379> ZRANGEBYSCORE myzset (1 (2
(empty list or set)

simple keydb (eqalpha/keydb:x86_64_v0.9.5)

keydb-cli -a password
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> ZADD myzset 1 "one"
(integer) 1
127.0.0.1:6379> ZADD myzset 2 "two"
(integer) 1
127.0.0.1:6379> ZADD myzset 3 "three"
(integer) 1
127.0.0.1:6379> ZRANGEBYSCORE myzset -inf +inf
1) "one"
2) "two"
3) "three"
127.0.0.1:6379> ZRANGEBYSCORE myzset (1 (2
(nil)

Is this RESP protocol-compatible with mainline Redis?

And if it is, perhaps a note mentioning that in the readme would serve beneficial.

Does KeyDB active-active need sentinel?

Does KeyDB require Redis Sentinel? While I can see how they exist here for being compatible with Redis failover, do I need Sentinel when setting up active-active replication?

That is, after the master fails, I can continue writing to the replica with just switching the IP address. Do I need to do anything more?

use dlmopen for modules to clearly separate symbol namespace

https://github.com/JohnSully/KeyDB/blob/aa274960fff095c4c3cd570cdbaaabb9ca005651/src/module.cpp#L5210

refers to redis/redis#6125

can file a PR here too if desired.

Crash with active replication and multimaster active

I'm running a very basic Docker setup with 2 KeyDB instances, both are configured via their respective config before start and have no previous data.

I've also attempted enabling active replication and multi-master via config and then using replicaof commands on the running instances resulting in the same crash.

https://gist.github.com/PurpleIsEverything/7fb1c90654ad3e07f0b537ec9e4f4331

Thanks.

Versioning

I'm trying to understand the logic behind current versioning you use (e.g. 0.9.4 to 0.9.4-r2, instead of 0.9.5). I'm an Linux rpm packager and this type of versioning creates issues on the long term.

Regards,

Floren

CURP - fast replication nearly for free and without the current caveats

There is a "new" approach to very fast replication called CURP (Consistent Unordered Replication Protocol).

It shall not have the caveats the current replication scheme in Redis has and shall not be difficult to implement (actually it was already partially implemented for Redis to test it - don't know though where the source lies and what is the license).

Would you consider implementing such low hanging fruit?

I've made a similar ticket directly for Redis, but as Redis is under the hood of a company with specific opinions, I'm opening it here as well as I'd like Redis-like DBs thrive.

KeyDB reports very low redis_version

Hello!

First I'd like to thank you for all your hard work. I've noticed that via the INFO command, KeyDB is reporting a very low redis_version. This unfortunately breaks every piece of software which tests against this value.

Is it possible that instead of yielding the version of KeyDB in that field, it'd be better for compatibility purposes, to yield a version of Redis that the build is compatible with and maintain version information for KeyDB in a separate key like keydb_version?

Starting one client causes another to crash with latest build

https://gist.github.com/PurpleIsEverything/c22b4bb4242c887d5d796dce8500e55e

Could not connect to Redis when choosing a non-default port

Upon configuring KeyDB to use a non-default port the following error occurs:

$ keydb-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected>

In this instance I am using 6366 but it tries to connect to 6379 as shown above.
I've set the port to 6366 when running install_sever.sh and the config file contains the following:
port 6366
KeyDB is running in the background just fine and my website happily uses it through port 6366.

OS: Ubuntu 16.04

Add Docker link to Readme

Today docker is vastly used so I really recommend updating project README with link to the docker image at https://hub.docker.com/r/eqalpha/keydb

KeyDB compile error (CentOS)

ENV:
CentOS 6.5 x86_64 with devtoolset-3-gcc (4.9.2)
I use
make CFLAGS="-march=haswell -m128bit-long-double -m64 " MALLOC=jemalloc
I get this info:
server.cpp: In function 'char* genRedisInfoString(const char*)':
server.cpp:4453:29: error: expected ')' before 'PRIu64'
"long_lock_waits:%" PRIu64 "\r\n",
^
server.cpp:4459:36: warning: spurious trailing '%' in format [-Wformat=]
fastlock_getlongwaitcount());
^
server.cpp:4459:36: warning: too many arguments for format [-Wformat-extra-args]
make[1]: *** [server.o] Error 1
make[1]: Leaving directory `/opt/opstoolset/source/redis/src/KeyDB-0.9.4-r2/src'

How to fix this ? very very thanks :-)

SO_REUSEADDR may be a typo

The README.md says,

KeyDB currently relies on SO_REUSEADDR's load balancing behavior which is available only in Linux

I think it should be SO_REUSEPORT here.