mnesia replication

[Serge Aleynikov]

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 \[a@REDACTED\]

(a@REDACTED)1> mnesia:create_schema([a@REDACTED, b@REDACTED]).
ok
(a@REDACTED)2> mnesia:start().
ok

(b@REDACTED)1> mnesia:start().
ok

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

(b@REDACTED)2> q().
ok

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

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 
b@REDACTED 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 b@REDACTED it crashed with a core dump:

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

What I did next was I manually copied the "schema.DAT" file from 
a@REDACTED, 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 \[a@REDACTED\]
(b@REDACTED)1> mnesia:start().
ok

Then mnesia:del_table_copy/2 worked alright from node a@REDACTED:

(a@REDACTED)6> mnesia:del_table_copy(test, b@REDACTED).
{atomic,ok}

(b@REDACTED)2> mnesia:info().
...
opt_disc. Directory "/home/serge/tmp/Mnesia.b@REDACTED" is used.
use fallback at restart = false
running db nodes   = [a@REDACTED,b@REDACTED]
stopped db nodes   = []
master node tables = []
remote             = [test]
ram_copies         = []
disc_copies        = [schema]
disc_only_copies   = []
[{a@REDACTED,disc_copies}] = [test]
[{a@REDACTED,disc_copies},{b@REDACTED,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, r@REDACTED).
> 
> Once you do this you are not supposed to bring back the node r@REDACTED 
> 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
serge@REDACTED