Fragment not locked - again

[Wojtek Surowka]

I have sent the same question some time ago but could not get any solution.
Maybe this time I will be luckier, especially that I made new observations:

I have a fragmented table in Mnesia of type disc_only_copies. There is a 2GB
size limit for tables of that type, and this table grows continuously with
new data. Because of that I have the code which periodically (weekly) checks
sizes of fragments and adds new fragments (usually just one) if necessary.
The call I use to add a new fragment is:

mnesia:change_table_frag(name, {add_frag, [node()]}).

And it works, till it does not. Right now my table is in a state when any
call to add a new fragment returns

{aborted,{"add_frag: Fragment not locked",12}}

All earlier change_table_frag calls were successful, but it looks like at
certain moment something bad happened and since then adding a new fragment
to the table is not possible. Every time it returns the error message. Is it
a bug in Mnesia? Is there anything I could do to continue adding new
fragments?

Thanks,
Wojtek

[Dan Gudmundsson]

I only looked briefly the last time you pointed it out, and it does look strange, 

though I have not had time to dig deeper into it.

If you use fragmented tables to be able store larger tables on disk_only,

maybe you should look at https://github.com/klarna/mnesia_eleveldb or some

other backend. I have not used it myself but there are people on this list using it.

/Dan

[Wojtek Surowka]

Thank you for suggestion, I will investigate mnesia_eleveldb.

 

How about backups? If I have a table using an alternative backend, like LevelDB, can I still use regular mnesia:backup and mnesia:install_fallback functions to handle backups?

 

Thanks,

Wojtek

[Stanislav Ledenev]

Hi, Wojtek!

I remember your post about this problem. It is sad to hear that it still exists.

Just a wild guess checklist:

1. Are you running your node with -sname or -name options? 

2. Does the name of the node change in time? 

I have had problems with mnesia backups if the name of the node changes. 

Maybe this problem can be related to some node stuff...

вс, 19 сент. 2021 г. в 18:09, Wojtek Surowka <wojtek...@me.com>:

[Wojtek Surowka]

Hello!

Actually I run node with sname and this name never changes. About Mnesia backup problems vs node name it is as I understand widely known thing, and even Erlang docs include an example code in http://erlang.org/doc/apps/mnesia/Mnesia_chap7.html#backup showing how to change the node name in a backup. We have a variant of this code in our codebase and it is routinely used to run production db backups locally to investigate issues. Generally everything with Mnesia works well for us except for fragmented tables.

My question about backups was asked in the context that we use backups routinely, they are easy to use single files. Normally we handle them with mnesia:backup and mnesia:install_fallback calls. If we switch to an alternative backend, like LevelDB, will it still be the case?

Thanks,
Wojtek

From: Stanislav Ledenev <s.le...@gmail.com>
Sent: 29 September 2021 13:18
To: Wojtek Surowka <wojtek...@me.com>
Cc: erlang-questions <erlang-q...@erlang.org>
Subject: Re: Fragment not locked - again

Hi, Wojtek!
I remember your post about this problem. It is sad to hear that it still exists.
Just a wild guess checklist:
1. Are you running your node with -sname or -name options?
2. Does the name of the node change in time?

I have had problems with mnesia backups if the name of the node changes.
Maybe this problem can be related to some node stuff...

вс, 19 сент. 2021 г. в 18:09, Wojtek Surowka <mailto:wojtek...@me.com>: