DUMP command error with list

[krizald]

Search before asking

• I had searched in the issues and found no similar issues.

Version

OS: Debian 11 bulleye
KV Rocks: unstable, git_sha1:4ecb35b9
Redis: 6.2.10

Minimal reproduce step

Redis service: localhost:6381
KV Rocks: localhost:7381

1. Start Redis 6.2 with attached dump.rdb
   dump.zip

2. Dump Key "ABCD" , which is a list, from Redis to a local file

redis-cli -p 6381 --raw dump ABCD | head -c-1 > ABCD-REDIS.dump

3. Restore ABCD to KV rocks

cat ABCD-REDIS.dump | redis-cli -p 7381 -x restore ABCD 0
OK

4. Dump Key "ABCD" from KV Rocks to local file

redis-cli -p 7381 --raw dump ABCD | head -c-1 > ABCD-KVROCKS.dump

5. Restore ABCD back to Redis with a new name

cat ABCD-KVROCKS.dump | redis-cli -p 6381 -x restore NEW_ABCD 0
(error) ERR Bad data format

What did you expect to see?

Restore to Redis with KV Rocks dump should be successful

What did you see instead?

Restore to Redis with KV Rocks dump is failed. Error message:
(error) ERR Bad data format

Anything Else?

I attached 2 dump files. KV Rocks dump size is way bigger than the Redis one
ABCD_dump.zip

Are you willing to submit a PR?

• I'm willing to submit a PR!

[git-hulk]

@krizald Thanks for your report, I can confirm it works well in Redis7 but didn't work in Redis 6. Will investigate the reason while I get time.

[git-hulk]

@krizald Kvrocks now is using RDB_TYPE_LIST_QUICKLIST_2 to dump the list payload which is only supported in Redis7. Needs to change it to RDB_TYPE_LIST_QUICKLIST or RDB_TYPE_LIST encoding, to see if any guys would like to resolve this. If no, I will fix it this weekend.

[AntiTopQuark]

@krizald @git-hulk
I believe that if the result dumped from Redis 7 is in the RDB_TYPE_LIST_QUICKLIST_2 format, restoring it into Redis 6 would encounter the same issue.

The dump and restore commands themselves are inherently incompatible between different RDB versions.
Due to the existence of RDB_VERSION being encoded into the DUMP payload, Restore command will check the RDB_VERSION. The payload dumped in Redis 7 version cannot be used in Redis 6 version.

You can take a look at this code: https://github.com/redis/redis/blob/804110a487f048669aa9d9412e5789ec43f4fe39/src/cluster.c#L107"

The current KVRocks`s RDB_VERSION is 12, referencing the latest code of Redis.

[git-hulk]

@AntiTopQuark Thanks for your reply. For the DUMP command, it'd be better to support more Redis versions(at least since from Redis 4.0). And I have changed the RDB version to 6 in PR #2252, this issue should be caused by using the encoding RDB_TYPE_LIST_QUICKLIST_2 for the list which has been supported since Redis 7.0.0. I haven't tested other types like HASH/SET/ZSET yet, but I guess those data types should work well.

[AntiTopQuark]

@krizald :"I attached 2 dump files. KV Rocks dump size is way bigger than the Redis one"

Due to the fact that kvrocks does not support some compression encodings, the result of the dump command will be stored in its native string format, resulting in larger sizes.

[krizald]

@git-hulk

I tested with the most recent unstable KVRocks and Redis 6,2. String/Hashset/Set are ok. But dumping list is failed, when restore in Redis.

KV Rocks Server Info

# Server
version:unstable
kvrocks_version:unstable
redis_version:4.0.0
git_sha1:51ce175d

Redis Server Info

# Server
redis_version:6.2.10
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:8dfb0984f18c7765
redis_mode:standalone
os:Linux 5.10.0-22-amd64 x86_64

Here is the script I use to test list

redisConn="-p 6381"
kvrocksConn="-p 7381"
keyName="test-list"
redis-cli $redisConn del $keyName
redis-cli $kvrocksConn del $keyName
redis-cli $kvrocksConn lpush $keyName "A"
redis-cli $kvrocksConn lpush $keyName "B"
redis-cli $kvrocksConn lpush $keyName "D"
redis-cli $kvrocksConn --raw dump $keyName | head -c-1 | redis-cli $redisConn -x restore $keyName 0

Error message: (error) ERR Bad data format

[git-hulk]

@krizald Thanks for your detailed report. Then I know the root cause now and will fix it when I get time. @AntiTopQuark is also welcome to contribute if you're interested.

[AntiTopQuark]

@krizald Thanks for your detailed report. Then I know the root cause now and will fix it when I get time. @AntiTopQuark is also welcome to contribute if you're interested.

@git-hulk If you haven't started yet, I can accept this task

[git-hulk]

@AntiTopQuark Very much appreciate your offer. I'm still working on the controller and not start yet. Welcome to take this issue.