Currently, only when we persist the copied information on the disk, will we also save the lua script on the disk at the same time.
However, when I only have a single redis instance, I bgsave an RDB file but did not save the state of the lua scripts, so I cannot restore the lua scripts to another redis instance
Therefore, we can always save lua scripts in the rdb file, just like always save the module aux
see https://github.com/redis/redis/pull/9026 . thx
Comment From: ShooterIT
I think that makes sense, the comments of this commit https://github.com/redis/redis/commit/0429db3c652179ec539096939bd7b69fc53e7a56, we notice that
so maybe later we may want to remove the conditionals and always save/load scripts.
And i notice we have plan to implement one rdb parse lib, maybe we also want to expose scripts of server.
Comment From: madolson
Scripts today are not intended to be durably stored, they are just a cache. Scripts are intended to be supplied by the clients, not stored within Redis.
I think this should be discussed under the proposal to make functions that are more liked stored procedures: https://github.com/redis/redis/issues/8693
Comment From: menwenjun
@madolson I think redis data sets and scripts should be stored persistently, because they all exist in memory, are cached in some form, and are provided by the client. ie: I have a single instance. I want to trigger bgsave periodically to generate a snapshot, and I can restore some data through the snapshot, including the script cache, so I don’t need to execute SCRIPT EXISTS to determine whether the script exists, and then execute EVALSHA, Or always use EVAL, which may increase network overhead.
Comment From: madolson
@menwengit I understand what you are saying, I'm just saying that it's more complex than just storing the lua script cache in the RDB. Today scripts are NOT persistent and your proposed PR does NOT make them persistent, just slightly more persistent. The issue I linked is a more comprehensive suggestion for making scripts to be persistent and stored in RDB/AOF. So I don't think we should introduce a hack, and instead just think through the long term solution. I'm sorry that in the mean time we don't have a simple solution for you.
Comment From: menwenjun
@madolson Yes, I see. thx.