Mnesia creating table on release startup consistency

Questions / Help
1

at release startup, I’m creating mnesia tables with mnesia:create_table/2. That works however, every second startup all the tables are deleted and created again. To be clear if tables exist it is ok for my case for the call to mnesia:create_table/2 to fail with {aborted, {already_exists, <table name>}} and it is also happening every other startup. Can someone please explain that behavior and what am i doing wrong?

2 Likes
2

It sounds like tables get created inside a release/build and rebuilding may be removing the database(s).

What you may want to try is to set your mnesia dir for some other location in your vm.args
eg

-mnesia dir '"/var/lib/myapp/mnesia_dir"'
1 Like
3

my problem is happening without rebuilding, just stopping and restarting the release is enough to reproduce this problem. Also, my mnesia dir is set via sys.config and that seems to create tables in the right place.

1 Like
4

From the documentation:

Mnesia startup is asynchronous. The function call mnesia:start() returns the atom ok and then starts to initialize the different tables. Depending on the size of the database, this can take some time, and the application programmer must wait for the tables that the application needs before they can be used. This is achieved by using the function mnesia:wait_for_tables/2.

So, the problem could be if you try to initialize new tables without waiting for them to load.

1 Like
5

It could be helpful if you posted a snippet containing the calls to mnesia:create_table/2 including the parameters that you are using (type of tables, etc.)

By the way, have you created the schema? See the mnesia:create_schema/1 function. And also, are you working with a single node or with a cluster?

2 Likes
6

After long time i have revisited my problem and i found a way how to reproduce it reliably and also what seems to be a problem, however i still lack exact explanation for the observed behavior:

To reproduce:

  1. create mnesia schema on node X with mnesia dir dirX
  2. transplant schema (FALLBACK.BUP) into dir dirY
  3. run shell with node Y and mnesia dir dirY and try to create tables
  4. repeat step 3. multiple times (for the same tables)

In my case this procedure happened because of my misunderstanding how to configure shell and/or initialize database and compounded by the typo between step 1. and step 3. (node name “example” vs “exmple”).
I was not able to run my app because there was not schema so i figured inspired by some other project online that “transplant” of a schema/fallback into the correct folder wold help and it partially did. App was able to run but on each other run it would delete all the tables and create them new (schema was there but tables where not found therefore created).

I am still surprised why it would happen every other run? For me it would be more intuitive if it would always fail or if it would always found tables after first run. Does anyone have any idea what this would be the case?

7

There is an example in the documentation how you can change the node name stored inside the backup.

1 Like
8

Thank you, i looked but i was unable to find documentation you are referring to. Could you please provide a link to it?

also i’m still searching for the explanation why i got behavior like described above.

9

Erlang -- Mnesia System Information contains a code snippet to change the node name inside a backup.

1 Like
10

I have found it now, thank you.