https://redis.io/commands/migrate shows the following example:
MIGRATE 192.168.1.34 6379 "" 0 5000 KEYS key1 key2 key3
However when I send that command to Redis it returns a syntax error:
MIGRATE 192.168.1.34 6379 "" 0 5000 KEYS key1 key2 key3
-ERR syntax error
Modifying the command for my use it's returning that the key must be an empty string when I'm passing an empty string for key with the COPY argument, and the same syntax error without COPY:
MIGRATE 18.216.96.143 6379 "" 0 5000 KEYS target_key
-ERR syntax error
MIGRATE 18.216.96.143 6379 "" 0 5000 COPY KEYS target_key
-ERR When using MIGRATE KEYS option, the key argument must be set to the empty string
This command does not appear to be taking arguments as documented. Please advise.
INFO
$3363
# Server
redis_version:5.0.7
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:5f6bfe2b13cc4617
redis_mode:standalone
os:Linux 4.9.0-6-amd64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:8.3.0
process_id:1
run_id:49bdc1b9261eb40bb598b439ca4d56e3741c8b22
tcp_port:6379
uptime_in_seconds:168916
uptime_in_days:1
hz:10
configured_hz:10
lru_clock:4416814
executable:/data/redis-server
config_file:
Comment From: itamarhaber
Hello @TJNII
I can't seem to reproduce this issue:
127.0.0.1:6379> set foo bar
OK
127.0.0.1:6379> MIGRATE 127.0.0.1 6380 "" 0 5000 KEYS foo
OK
127.0.0.1:6379> INFO server
# Server
redis_version:5.0.7
redis_git_sha1:3c610b4e
redis_git_dirty:0
redis_build_id:6d8d0f04ea11f956
redis_mode:standalone
os:Darwin 19.2.0 x86_64
arch_bits:64
multiplexing_api:kqueue
atomicvar_api:atomic-builtin
gcc_version:4.2.1
process_id:47212
run_id:fadd6f129ddf3d78b4370bb7821e4d03b05d10ab
tcp_port:6379
uptime_in_seconds:33
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:4715467
executable:/Users/itamar/redis-server
config_file:
Comment From: TJNII
Redis-cli appears to behave differently than connecting directly to the Redis socket.
Start the server for the test:
tom@host ~ $ docker pull redis
Using default tag: latest
latest: Pulling from library/redis
Digest: sha256:7b84b346c01e5a8d204a5bb30d4521bcc3a8535bbf90c660b8595fad248eae82
Status: Image is up to date for redis:latest
docker.io/library/redis:latest
tom@host ~ $ docker run -d --name test_redis redis
e0e89d3f32efe8eef9e492c21bd504c379540fd6862a45ac2f485ca0d0b73288
Try the command using redis-cli, which correctly returns NOKEY:
tom@host ~ $ docker run --rm -ti --link test_redis:test_redis redis redis-cli -h test_redis
test_redis:6379> MIGRATE 127.0.0.1 6380 "" 0 5000 KEYS foo
NOKEY
test_redis:6379>
Try the command using netcat, mimicking how a SDK would issue the command, which returns the syntax error:
tom@host ~ $ docker run --rm -ti --link test_redis:test_redis debian
root@135deead4f5c:/# apt-get update
Get:2 http://deb.debian.org/debian buster InRelease [122 kB]
Get:1 http://security-cdn.debian.org/debian-security buster/updates InRelease [65.4 kB]
Get:3 http://deb.debian.org/debian buster-updates InRelease [49.3 kB]
Get:4 http://deb.debian.org/debian buster/main amd64 Packages [7907 kB]
Get:5 http://security-cdn.debian.org/debian-security buster/updates/main amd64 Packages [177 kB]
Get:6 http://deb.debian.org/debian buster-updates/main amd64 Packages [5792 B]
Fetched 8326 kB in 6s (1360 kB/s)
Reading package lists... Done
root@135deead4f5c:/# apt-get install -y netcat
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
netcat-traditional
The following NEW packages will be installed:
netcat netcat-traditional
0 upgraded, 2 newly installed, 0 to remove and 9 not upgraded.
Need to get 75.9 kB of archives.
After this operation, 156 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian buster/main amd64 netcat-traditional amd64 1.10-41.1 [66.9 kB]
Get:2 http://deb.debian.org/debian buster/main amd64 netcat all 1.10-41.1 [9034 B]
Fetched 75.9 kB in 0s (321 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package netcat-traditional.
(Reading database ... 6674 files and directories currently installed.)
Preparing to unpack .../netcat-traditional_1.10-41.1_amd64.deb ...
Unpacking netcat-traditional (1.10-41.1) ...
Selecting previously unselected package netcat.
Preparing to unpack .../netcat_1.10-41.1_all.deb ...
Unpacking netcat (1.10-41.1) ...
Setting up netcat-traditional (1.10-41.1) ...
update-alternatives: using /bin/nc.traditional to provide /bin/nc (nc) in auto mode
Setting up netcat (1.10-41.1) ...
root@135deead4f5c:/# nc test_redis 6379
MIGRATE 127.0.0.1 6380 "" 0 5000 KEYS foo
-ERR syntax error
^C
root@135deead4f5c:/#
Comment From: itamarhaber
Thanks for the extra info - it is indeed reproducible when ncing to a dockerized Redis server but not when Redis is running outside the container. Weird.
Comment From: TJNII
It seems to be redis-cli vs nc, not Docker, I compiled 5.0.7 and ran it locally (thereby taking Docker out of the loop) with the same result.
$ nc 127.0.0.1 6379
MIGRATE 127.0.0.1 6380 "" 0 5000 KEYS foo
-ERR syntax error
INFO
$3255
# Server
redis_version:5.0.7
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:3c9bd71fdd772fd7
redis_mode:standalone
os:Linux 4.9.0-12-amd64 x86_64
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:6.3.0
process_id:20683
run_id:fd4dcc98e32ac5412be796d75c4a83fa2199d892
tcp_port:6379
uptime_in_seconds:67
uptime_in_days:0
hz:10
configured_hz:10
lru_clock:4933956
executable:/tmp/tmp.rsatpBwIBd/redis-5.0.7/./src/redis-server
config_file:
If I fire up netcat as a listener and connect redis-cli to it I see redis-cli is sending the command in RESP:
*8
$7
MIGRATE
$9
127.0.0.1
$4
6380
$0
$1
0
$4
5000
$4
KEYS
$3
foo
When I try and send this to Redis-server via nc I get no response. I do see with tcpdump that there is a lot of chatter between redis-server and redis-cli when redis-cli is started, so I may be missing something. I've never tried to use RESP for requests, as I'm usually only hand driving like this to make sure I have the semantics of a command correct before falling back to a SDK.
Comment From: itamarhaber
Thanks for continuing the investigation :)
So, this is indeed reproducible against a local 5.0.7, but doesn't reproduce with 6RC1 & the unstable tip (#facepalming myself for triaging on unstable).
The reason this is happening is because of the empty string ('""'). When you're using nc to send the non-RESP form, that's an inline command, and v5 and earlier seem to dislike empty strings in them. Even trying to SET foo "" fails in a similar fashion.
This has been fixed via 0f28ea16a7f1892d73a85e2ea88c9dcdc855ea04 and perhaps should be backported - ping @antirez