thinker0 opened a new issue, #3498:
URL: https://github.com/apache/kvrocks/issues/3498
## Summary
With `migrate-type redis-command`, migrating a slot that contains a hash
key whose name has a `{tag}` aborts mid-stream:
```
[I][slot_migrate.cc:373] The key ij/staging/{N/<rand>/<id>} successfully
migrated
[E][slot_migrate.cc:203] Failed to send snapshot of slot(s) <range>.
Error: failed to migrate a key ij/staging/{N/<rand>/<id>}:101:
failed to migrate complex key: failed to send commands to restore a key:
wrong response from the destination node:
got invalid response of length 61: -MOVED <slot> <host>:<port>
```
The slot number returned in the `MOVED` reply is **different** from
`CLUSTER KEYSLOT <key>` for the same key (we saw parent=5466 and the
reported MOVED=5465). The destination is computing the slot from an
encoded sub-key buffer that does not preserve the `{tag}` hashtag, so
the destination's command dispatcher believes that sub-key belongs to a
different slot it does not own → MOVED, abort.
## Workaround
`migrate-type raw-key-value` transfers each key as a RocksDB blob and
does not decompose complex keys, so the sub-key hashing path is never
exercised. The same migration that fails with `redis-command` completes
in seconds with `raw-key-value`.
We recommend documenting `raw-key-value` as the preferred type for
production slot migration until the `redis-command` path is fixed.
## Repro (vanilla setup)
1. Two-shard cluster, `migrate-type redis-command` (current default).
2. Insert a hash with a tag: `HSET ij/staging/{T1}:101 f1 v1 f2 v2`.
3. Trigger slot migration that includes the slot of `{T1}`.
4. Migration aborts with the MOVED error above.
## Versions
- Apache Kvrocks 2.15.0
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
