0
votes

So running mnesia in a multi-node (2 node) cluster with disc_copies as an option, when I log onto the server and inspect the directory contents with ls -l, I see the following mnesia table sizes:

Node 1:

-rw-r--r-- 1 root root      8 Jul 25 20:58 applications.DCD
-rw-r--r-- 1 root root   1530 Jul 26 00:25 applications.DCL
-rw-r--r-- 1 root root    132 Jul 26 01:10 LATEST.LOG
-rw-r--r-- 1 root root      8 Jul 25 20:58 table.DCD
-rw-r--r-- 1 root root 237451 Jul 26 00:43 table.DCL
-rw-r--r-- 1 root root      8 Jul 25 20:58 kite_table.DCD
-rw-r--r-- 1 root root  80707 Jul 26 00:43 kite_table.DCL
-rw-r--r-- 1 root root  14730 Jul 26 01:03 schema.DAT

Node 2:

-rw-r--r-- 1 root root    196 Jul 26 01:13 DECISION_TAB.LOG
-rw-r--r-- 1 root root   1238 Jul 26 01:10 applications.DCD
-rw-r--r-- 1 root root    132 Jul 26 01:13 LATEST.LOG
-rw-r--r-- 1 root root 233483 Jul 26 01:10 table.DCD
-rw-r--r-- 1 root root  80674 Jul 26 01:10 kite_table.DCD
-rw-r--r-- 1 root root  17032 Jul 26 01:09 schema.DAT

But extracting the same data with a call to :mnesia.info(), I see:

Node 1:

table         : with 64       records occupying 38477    words of mem
kite_table    : with 1        records occupying 13562    words of mem
applications: with 4        records occupying 488      words of mem
schema         : with 9        records occupying 1486     words of mem

Node 2:

table         : with 64       records occupying 38477    words of mem
kite_table    : with 1        records occupying 13562    words of mem
applications: with 4        records occupying 488      words of mem
schema         : with 9        records occupying 1486     words of mem

Then it appears the data is the same size and consistent. Can anyone explain the apparent inconsistency?

The code below shows a typical call done in the system for :mnesia.create_table/2

opts = [
  {:attributes, [id: nil, data: %{}]},
  {:type, :set},
  {:index, []},
  {:disc_copies, [node() | Node.list([:visible])]}
]

:mnesia.create_table(:kite_table, opts)
1
Can you provide the code that creates database. Arguments of function mnesia:create_table will be helpful.Yuri Ginsburg
Updated @YuriGinsburg with typical call to create_table/2, thanksNona
I started two nodes on my computer, then used {disc_copies, [n1@mymbp2, n2@mymbp2]} in the mnesia:create_table() function, and I'm seeing the same thing as you.7stud

1 Answers

1
votes

My reading of the erlang mnesia docs indicates that that may be a normal occurrence:

When starting Mnesia, a .LOG file called LATEST.LOG is created and placed in the database directory. This file is used by Mnesia to log disc-based transactions. This includes all transactions that write at least one record in a table that is of storage type disc_copies or disc_only_copies. The file also includes all operations that manipulate the schema itself, such as creating new tables. The log format can vary with different implementations of Mnesia. The Mnesia log is currently implemented in the standard library module disk_log in Kernel.

The log file grows continuously and must be dumped at regular intervals. "Dumping the log file" means that Mnesia performs all the operations listed in the log and place the records in the corresponding .DAT, .DCD, and .DCL data files. For example, if the operation "write record {foo, 4, elvis, 6}" is listed in the log, Mnesia inserts the operation into the file foo.DCL. Later, when Mnesia thinks that the .DCL file is too large, the data is moved to the .DCD file. The dumping operation can be time consuming if the log is large. Notice that the Mnesia system continues to operate during log dumps.

By default Mnesia either dumps the log whenever 100 records have been written in the log or when three minutes have passed. This is controlled by the two application parameters -mnesia dump_log_write_threshold WriteOperations and -mnesia dump_log_time_threshold MilliSecs.

I do wish the docs for info() said something like:

Retrieves the table information from the RAM copies of the table.

The docs also say:

disc_copies. This property specifies a list of Erlang nodes where the table is kept in RAM and on disc. All updates of the table are performed in the actual table and are also logged to disc....Each transaction performed on the table is appended to a LOG file and written into the RAM table.

What do the file sizes look like after you shut down your application? I would expect them to be equivalent.