UDF backup and restoration issue

udf

#1

Hi, I am using UDFs where a UDF module is dependent on other modules. For example: If I am having 3 UDFs as UDF-A, UDF-B & UDF-C. And dependency among them is defined as

  1. UDF-A is dependent on UDF-B
  2. UDF-B is dependent on UDF-C

I need to register UDFs in the order of UDF-C, UDF-B and UDF-A in my aerospike. I am facing issue when I am trying to take the backup of my UDFs. The restoration script of UDF doesn’t work as it doesn’t register UDFs in the order required.

I have checked the backup file created and .lua files are not in the order w.r.t. dependencies defined.

How is the order of lua files defined in backup script? Thanks in advance


#2

Hi, Just to add - I have also noticed that ordering of modules in the backfile created is similar to the ordering of modules when I use “show modules” command.


#3

Hi, restoration of UDFs is solved by flag “-w” as mentioned in Other options in https://www.aerospike.com/docs/tools/backup/asrestore.html. But any leads on how ordering of UDFs are maintained?


#4

I’ve been working to update the UDF developer guide, and there will be a section about dependent Lua modules. The changes aren’t pushed yet, though, so check the docs again soon.

https://www.aerospike.com/docs/udf/udf_guide.html

What you need to do is register your all your Lua modules with Aerospike, for example using aql.

aql> register module 'udf-c.lua'
OK, 1 module added.

aql> register module 'udf-b.lua'
OK, 1 module added.

aql> register module 'udf-a.lua'
OK, 1 module added.

The order of registration doesn’t really matter, it just needs to happen ahead of you calling a function of udf-A. By registering it with the cluster you are ensuring that the UDF file will be copied to all the nodes of the cluster, so they each have a local copy in their shared metadata (smd) to execute against.

In asrestore make sure to use the --wait flag to wait for the UDFs to ship to all the nodes of the cluster you’re restoring to, ahead of records being restored.