4986310945
New config: `import-mode (yes|no)` New command: `CLIENT IMPORT-SOURCE (ON|OFF)` The config, when set to `yes`, disables eviction and deletion of expired keys, except for commands coming from a client which has marked itself as an import-source, the data source when importing data from another node, using the CLIENT IMPORT-SOURCE command. When we sync data from the source Valkey to the destination Valkey using some sync tools like [redis-shake](https://github.com/tair-opensource/RedisShake), the destination Valkey can perform expiration and eviction, which may cause data corruption. This problem has been discussed in https://github.com/redis/redis/discussions/9760#discussioncomment-1681041 and Redis already have a solution. But in Valkey we haven't fixed it by now. E.g. we call `set key 1 ex 1` on the source server and transfer this command to the destination server. Then we call `incr key` on the source server before the key expired, we will have a key on the source server with a value of 2. But when the command arrived at the destination server, the key may be expired and has deleted. So we will have a key on the destination server with a value of 1, which is inconsistent with the source server. In standalone mode, we can use writable replica to simplify the sync process. However, in cluster mode, we still need a sync tool to help us transfer the source data to the destination. The sync tool usually work as a normal client and the destination works as a primary which keep expiration and eviction. In this PR, we add a new mode named 'import-mode'. In this mode, server stop expiration and eviction just like a replica. Notice that this mode exists only in sync state to avoid data inconsistency caused by expiration and eviction. Import mode only takes effect on the primary. Sync tools can mark their clients as an import source by `CLIENT IMPORT-SOURCE`, which work like a client from primary and can visit expired keys in `lookupkey`. **Notice: during the migration, other clients, apart from the import source, should not access the data imported by import source.** --------- Signed-off-by: lvyanqi.lyq <lvyanqi.lyq@alibaba-inc.com> Signed-off-by: Yanqi Lv <lvyanqi.lyq@alibaba-inc.com> Co-authored-by: Madelyn Olson <madelyneolson@gmail.com> |
||
---|---|---|
.. | ||
assets | ||
cluster | ||
helpers | ||
integration | ||
modules | ||
rdma | ||
sentinel | ||
support | ||
tmp | ||
unit | ||
CMakeLists.txt | ||
instances.tcl | ||
README.md | ||
test_helper.tcl |
Valkey Test Suite
Overview
Integration tests are written in Tcl, a high-level, general-purpose, interpreted, dynamic programming language [source].
runtest
is the main entrance point for running integration tests.
For example, to run a single test;
./runtest --single unit/your_test_name
# For additional arguments, you may refer to the `runtest` script itself.
The normal execution mode of the test suite involves starting and manipulating
local valkey-server
instances, inspecting process state, log files, etc.
The test suite also supports execution against an external server, which is
enabled using the --host
and --port
parameters. When executing against an
external server, tests tagged external:skip
are skipped.
There are additional runtime options that can further adjust the test suite to
match different external server configurations. All options are listed by
./runtest --help
. The following table is just a subset of the options:
Option | Impact |
---|---|
--singledb |
Only use database 0, don't assume others are supported. |
--ignore-encoding |
Skip all checks for specific encoding. |
--ignore-digest |
Skip key value digest validations. |
--cluster-mode |
Run in strict Valkey Cluster compatibility mode. |
--large-memory |
Enables tests that consume more than 100MB |
--tls |
Run tests with TLS. See below. |
--tls-module |
Run tests with TLS, when TLS support is built as a module. |
--help |
Displays the full set of options. |
Running with TLS requires the following preparations:
- Build Valkey is TLS support, e.g. using
make BUILD_TLS=yes
, ormake BUILD_TLS=module
. - Run
./utils/gen-test-certs.sh
to generate a root CA and a server certificate. - Install TLS support for TCL, e.g. the
tcl-tls
package on Debian/Ubuntu.
Additional tests
Not all tests are included in the ./runtest
scripts. Some additional entry points are provided by the following scripts, which support a subset of the options listed above:
./runtest-cluster
runs more extensive tests for Valkey Cluster. Some cluster tests are included in./runtest
, but not all../runtest-sentinel
runs tests of Valkey Sentinel../runtests-module
runs tests of the module API.
Debugging
You can set a breakpoint and invoke a minimal debugger using the bp
function.
... your test code before break-point
bp 1
... your test code after break-point
The bp 1
will give back the tcl interpreter to the developer, and allow you to interactively print local variables (through puts
), run functions and so forth [source].
bp
takes a single argument, which is 1
for the case above, and is used to label a breakpoint with a string.
Labels are printed out when breakpoints are hit, so you can identify which breakpoint was triggered.
Breakpoints can be skipped by setting the global variable ::bp_skip
, and by providing the labels you want to skip.
The minimal debugger comes with the following predefined functions.
- Press
c
to continue past the breakpoint. - Press
i
to print local variables.
Tags
Tags are applied to tests to classify them according to the subsystem they test, but also to indicate compatibility with different run modes and required capabilities.
Tags can be applied in different context levels:
start_server
contexttags
context that bundles several tests together- A single test context.
The following compatibility and capability tags are currently used:
Tag | Indicates |
---|---|
external:skip |
Not compatible with external servers. |
cluster:skip |
Not compatible with --cluster-mode . |
large-memory |
Test that requires more than 100MB |
tls:skip |
Not compatible with --tls . |
needs:repl |
Uses replication and needs to be able to SYNC from server. |
needs:debug |
Uses the DEBUG command or other debugging focused commands (like OBJECT REFCOUNT ). |
needs:pfdebug |
Uses the PFDEBUG command. |
needs:config-maxmemory |
Uses CONFIG SET to manipulate memory limit, eviction policies, etc. |
needs:config-resetstat |
Uses CONFIG RESETSTAT to reset statistics. |
needs:reset |
Uses RESET to reset client connections. |
needs:save |
Uses SAVE or BGSAVE to create an RDB file. |
When using an external server (--host
and --port
), filtering using the
external:skip
tags is done automatically.
When using --cluster-mode
, filtering using the cluster:skip
tag is done
automatically.
When not using --large-memory
, filtering using the largemem:skip
tag is done
automatically.
In addition, it is possible to specify additional configuration. For example, to
run tests on a server that does not permit SYNC
use:
./runtest --host <host> --port <port> --tags -needs:repl