Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huge lists do not migrate fully between cluster nodes #4143

Closed
chakaz opened this issue Nov 18, 2024 · 2 comments · Fixed by #4154
Closed

Huge lists do not migrate fully between cluster nodes #4143

chakaz opened this issue Nov 18, 2024 · 2 comments · Fixed by #4154
Assignees
Labels
bug Something isn't working

Comments

@chakaz
Copy link
Collaborator

chakaz commented Nov 18, 2024

(this may apply to other data types as well)

To reproduce:

  • Run 2 cluster-mode Dragonfly processes (with with --port=7001 and --port=7002, and pass --cluster_mode=yes to both)
  • Configure them to have all slots belong to the first:
./cluster_mgr.py --action=config_single_remote --target_port=7001
./cluster_mgr.py --action=attach --target_port=7001 --attach_port=7002
  • Debug populate a huge list on the node with the slots:
$ redis-cli -p 7001
localhost:7001> debug populate 1 l: 1000 RAND TYPE list ELEMENTS 500000
OK
localhost:7001> llen l::0
(integer) 500000
  • Migrate all slots to second node:
./cluster_mgr.py --action=migrate --slot_start=0 --slot_end=16383 --target_port=7002
  • Note the issue:
localhost:7002> llen l::0
(integer) 4096
localhost:7002> memory usage l::0
(integer) 86064
@chakaz chakaz added the bug Something isn't working label Nov 18, 2024
@chakaz chakaz self-assigned this Nov 18, 2024
@adiholden adiholden added this to the dfly cluster v4 milestone Nov 18, 2024
@anadion
Copy link

anadion commented Nov 19, 2024

We hame similar problem with RENAME command and big zset keys.

redis_version:6.2.11
dragonfly_version:df-v1.24.0
redis_mode:standalone
127.0.0.1:6379[14]> type ipv4
zset
127.0.0.1:6379[14]> ZCARD ipv6_tmp
(integer) 7391471
127.0.0.1:6379[14]> RENAME ipv6_tmp ipv6
OK
(6.75s)
127.0.0.1:6379[14]> ZCARD ipv6
(integer) 4092

@chakaz
Copy link
Collaborator Author

chakaz commented Nov 19, 2024

Yes @anadion, that is due to the same root cause. Thanks for reporting!

chakaz added a commit that referenced this issue Nov 19, 2024
We have an internal utility tool that we use to deserialize values in
some use cases:

* `RESTORE`
* Cluster slot migration
* `RENAME`, if the source and target shards are different

We [recently](#3760)
changed this area of the code, which caused this regression as it only
handled RDB / replication streams.

Fixes #4143
@chakaz chakaz closed this as completed in 24a1ec6 Nov 20, 2024
adiholden pushed a commit that referenced this issue Nov 20, 2024
* fix: Huge entries fail to load outside RDB / replication

We have an internal utility tool that we use to deserialize values in
some use cases:

* `RESTORE`
* Cluster slot migration
* `RENAME`, if the source and target shards are different

We [recently](#3760)
changed this area of the code, which caused this regression as it only
handled RDB / replication streams.

Fixes #4143
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants