You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Hello, we are experiencing a weird bug where all our values become “7” using the HSETEX command when syncing dragonfly nodes.
To Reproduce
We have two 8gb dragonfly nodes in kubernetes and one operator. Version v1.1.9 of Helm Chart for operator, and we are running with backup: dbfilename=anbdb with hourly snapshot.
Populate the database with: HSETEX a 86400 x 1 y 3 z 4
and let it sync, then if I delete one of the pods, then the values after syncing in the deleted pod will become all “7”:
hgetall a
1) "x"
2) "7"
3) "z"
4) "7"
5) "y"
6) "7"
Expected behavior
Expected values to be as before sync.
Screenshots
NA
Environment (please complete the following information):
OS: Ubuntu 22.04.5 LTS
Kernel: 5.15.0-1086-azure
Containerized?: kubernetes
Dragonfly Version: 1.26.2
we experienced this half a year ago too (didnt report it though) but all the values were then "6" - so at least now we know its not the devil roaming in there
The text was updated successfully, but these errors were encountered:
Describe the bug
Hello, we are experiencing a weird bug where all our values become “7” using the HSETEX command when syncing dragonfly nodes.
To Reproduce
We have two 8gb dragonfly nodes in kubernetes and one operator. Version v1.1.9 of Helm Chart for operator, and we are running with backup: dbfilename=anbdb with hourly snapshot.
Populate the database with:
HSETEX a 86400 x 1 y 3 z 4
and let it sync, then if I delete one of the pods, then the values after syncing in the deleted pod will become all “7”:
Expected behavior
Expected values to be as before sync.
Screenshots
NA
Environment (please complete the following information):
OS: Ubuntu 22.04.5 LTS
Kernel: 5.15.0-1086-azure
Containerized?: kubernetes
Dragonfly Version: 1.26.2
we experienced this half a year ago too (didnt report it though) but all the values were then "6" - so at least now we know its not the devil roaming in there
The text was updated successfully, but these errors were encountered: