Hey everyone! I’m trying to migrate from Redis to DragonflyDB. I’m using the ioredis
and @bull-board/api
packages for Redis.
I set up DragonflyDB on port 6380, and ran redis-cli -p 6380
to get into it. I then ran replicaof local 6379
, and dbsize
showed the correct data. However, I then restarted my app and got met with the error “Failed to handle unlocked job in active”.
What’s the proper way to migrate from Redis to DragonflyDB? I already tried riot-redis
to no avail.
@inclusive-numbat apologies for the ping, but I see you’re online ^^;
If you are using bullmq underneath, we do not yet support it. See the open issue in the repo
Ah. Could you point me to the issue?
@inclusive-numbat so, I built from source and used the --default_lua_config=allow-undeclared-keys
parameter to get it running. However, it seems that it’s not being utilized efficiently? Is there any tweaking/tuning I can do? I have Dragonfly running on a dedicated 8 core 16GB VPS, but it’s using very little resources and puts many jobs into “waiting” rather than processing them…
Try using --default_lua_config=allow-undeclared-keys,disable-atomicty
but we do not officially support bull, yet
Tell us if it improves things on your end
@inclusive-numbat doesn’t seem to work
I20230601 18:04:00.422749 3223497 init.cc:69] ./dragonfly running in opt mode.
I20230601 18:04:00.423955 3223497 dfly_main.cc:592] Starting dragonfly df-dev-0000000
W20230601 18:04:00.424810 3223497 dfly_main.cc:629] SWAP is enabled. Consider disabling it when running Dragonfly.
I20230601 18:04:00.425529 3223497 dfly_main.cc:632] maxmemory has not been specified. Deciding myself....
I20230601 18:04:00.425748 3223497 dfly_main.cc:636] Found 15.62GiB available memory. Setting maxmemory to 12.50GiB
I20230601 18:04:00.462266 3223504 uring_proactor.cc:158] IORing with 1024 entries, allocated 102720 bytes, cq_entries is 2048
I20230601 18:04:00.494704 3223497 proactor_pool.cc:77] Running 16 io threads
F20230601 18:04:00.494937 3223497 script_mgr.cc:49] Check failed: !err Invalid flag: disable-atomicty
*** Check failure stack trace: ***
@ 0x5590d3620000 google::LogMessage::Fail()
@ 0x5590d36274d7 google::LogMessage::SendToLog()
@ 0x5590d361fa13 google::LogMessage::Flush()
@ 0x5590d36213af google::LogMessageFatal::~LogMessageFatal()
@ 0x5590d32f7beb dfly::ScriptMgr::ScriptMgr()
@ 0x5590d3313544 dfly::ServerFamily::ServerFamily()
@ 0x5590d32b41ac dfly::Service::Service()
@ 0x5590d326164b dfly::(anonymous namespace)::RunEngine()
@ 0x5590d3258508 main
@ 0x7f05b6741d90 (unknown)
@ 0x7f05b6741e40 __libc_start_main
@ 0x5590d325ce65 _start
*** SIGABRT received at time=1685642640 on cpu 11 ***
PC: @ 0x7f05b67aea7c (unknown) pthread_kill
[1] 3223497 IOT instruction (core dumped) ./dragonfly --default_lua_flags=allow-undeclared-keys,disable-atomicty
When running --help
I get this:
Flags from /server/script_mgr.cc:
--default_lua_flags (Configure default flags for running Lua scripts:
- Use 'allow-undeclared-keys' to allow accessing undeclared keys,
- Use 'disable-atomicity' to allow running scripts non-atomically.
Specify multiple values separated by space, for example
'allow-undeclared-keys disable-atomicity' runs scripts non-atomically and
allows accessing undeclared keys); default: "";
--lua_auto_async (If enabled, call/pcall with discarded values are
automatically replaced with acall/apcall.); default: false;
Ah, seems that ./dragonfly --default_lua_flags='allow-undeclared-keys disable-atomicity' --alsologtostderr
works
Doesn’t really seem to change anything though…
Actually if anything it seems to have made things slightly worse
@inclusive-numbat I can give you moderator permissions on my site to view bull-board if you want, if that’ll help with solving issues
@inclusive-numbat I just noticed something really weird – the Waiting section of my Delivery queue (there’s an Inbox and Delivery queue) just jumped from 0 to 7,000 in a split second, and this never happened on Redis. I wonder if there’s some scheduling issues
@winsome-nautilus
- Yes, allow-undeclared-keys makes Dragonfly slower, a lot. Scripts that access undeclared keys are unpredictable. Unpredictability and multi-threading don’t mix well
- Roman forgot an
i
: its disable-atomicity
- Please note that from
1.4.0
the flag will change to default_lua_flags
We have in our plans to check compatibility with Bull and we’ll check your issues. disable-atomicity
actually disables atomicity and it means that multiple scripts can operate on the same set of keys at the same time. If the script requires atomicity for correct execution, it won’t work properly in this mode. If you’re not sure, please don’t run them with this mode - it can lead to all kinds of undefined behavior and possible bugs.
We’re happy to see you using Dragonfly. However currently we still have some issues with some of the popular frameworks. We hope it’ll improve in the future