mnesia replication

Serge Aleynikov <>
Wed Aug 10 18:06:03 CEST 2005


mnesia:del_table_copy/2, seems to have a restriction that the node from 
which the replica is to be deleted should *not* have schema stored on disk:

~/tmp>erl -sname a
~/tmp>erl -sname b -mnesia extra_db_nodes \[\]

()1> mnesia:create_schema([, ]).
ok
()2> mnesia:start().
ok

()1> mnesia:start().
ok

()3> mnesia:create_table(test,
   [{disc_copies, []},{ram_copies, []}]).
{atomic,ok}

()2> q().
ok

()4> mnesia:del_table_copy(test, ).
{aborted,{not_active,"All replicas on diskfull nodes are not active yet",
                      test,
                      []}}
------------

What's the advantage/disadvantage of creating the disk-based schema on 
each node vs. keeping it on a subset of nodes?

In the configuration below does it make sense to keep the schema on disk 
only on the Master/Standby nodes?

------------
On a separate note, I tried to emulate a disk crash on node 
 with a disk-copy of the schema by wiping out the content 
of mnesia directory, and attempting to recover that mnesia node.  Upon 
startup of mnesia on  it crashed with a core dump:

  ** FATAL ** Failed to merge schema: Incompatible schema storage types 
(local). on  storage ram_copies, on  storage 
disc_copies

What I did next was I manually copied the "schema.DAT" file from 
, and started mnesia.

~/tmp>mkdir Mnesia.b\@devlinuxpro/
~/tmp>cp Mnesia.a\@devlinuxpro/schema.DAT Mnesia.b\@devlinuxpro/

~/tmp>erl -sname b -mnesia extra_db_nodes \[\]
()1> mnesia:start().
ok

Then mnesia:del_table_copy/2 worked alright from node :

()6> mnesia:del_table_copy(test, ).
{atomic,ok}

()2> mnesia:info().
...
opt_disc. Directory "/home/serge/tmp/" is used.
use fallback at restart = false
running db nodes   = []
stopped db nodes   = []
master node tables = []
remote             = [test]
ram_copies         = []
disc_copies        = [schema]
disc_only_copies   = []
[{,disc_copies}] = [test]
[{,disc_copies},{,disc_copies}] = [schema]
...

I am not sure if this is the right way to get rid of a faulty replica of 
a table in case of a disk-hosted schema, but this approach seems to work.

Serge

Chandrashekhar Mullaparthi wrote:
> 
> On 9 Aug 2005, at 21:28, Serge Aleynikov wrote:
> 
>> Chandrashekhar Mullaparthi wrote:
>>
>>>> Is this a good approach in terms of avoiding extensive locking 
>>>> overhead in trying to load multiple tables with preserving 
>>>> referential integrity of data accross several tables?
>>>
>>> Have you considered using sticky locks? They are quite useful if you 
>>> are only ever going to write to mnesia on one node at a time.
>>
>>
>> I am experimenting with several writing methods including table-level 
>> locks, sticky locks, and backup-restore technique (suggested by Vance 
>> in one of the former emails), but haven't come to a conclusion yet 
>> which technique provides better performance in case of the following 
>> mnesia configuration and size of the database of about 700M:
>>
>>   Master   -------------- RamCopy1
>>   DiskCopy ------+        ...
>>     |            |        ...
>>     |            +------- RamCopyN
>>   Standby
>>   DiskCopy
>>
>> All writes happen either at the Master or at Standby (if Master is 
>> down) node.
>>
>> What I need to ensure is that:
>>
>> 2. It should be possible to delete table copies of RamCopyK node from 
>> the mnesia schema on Master/Standby nodes, while the RamCopyK host is 
>> off-line.
> 
> You can do this using mnesia:del_table_copy/3
> 
> mnesia:del_table_copy(schema, ).
> 
> Once you do this you are not supposed to bring back the node  
> with it's old database. The results are "undefined" according to the 
> documentation.
> 
>>
>> 5. The should be no replication of data between RamCopy nodes, only 
>> from Master/Slave to RamCopy nodes.
> 
> 
> AFAIK, this is not possible with mnesia. But as long as you are not 
> going to perform updates on the RAM copy nodes, there will not be any 
> replication traffic between these nodes - it will always be from 
> master/slave to the ram copy nodes.
> 
>> I am not sure how to deal with #2 and #5...
> 
> 
> hope this helps.
> Chandru

-- 
Serge Aleynikov
R&D Telecom, IDT Corp.
Tel: (973) 438-3436
Fax: (973) 438-1464




More information about the erlang-questions mailing list