mnesia replication

[Serge Aleynikov]

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:
1. RamCopy nodes can be added or removed as servers get added or removed 
to/from the network.

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.

3. Inavailability of both Master and Stadby nodes should not impact the 
accessibility of data on any RamCopy.

4. If at startup a RamCopy node detects no Master/Standby nodes, it 
should be able to load the database image from disk.

5. The should be no replication of data between RamCopy nodes, only from 
Master/Slave to RamCopy nodes.

To address the issues above,

While the following configuration
   mnesia:create_schema([
     a@REDACTED, b@REDACTED, r@REDACTED, ..., r@REDACTED])
   mnesia:create_table(some_table,
     [{disc_copies, [a@REDACTED, b@REDACTED]},
      {ram_copies,  [r@REDACTED, ..., r@REDACTED]})

solves #3;

mnesia:add_table_copy/3 and mnesia:del_table_copy/2 takes case of #1;
mnesia:wait_for_tables/2 and mnesia:force_load_table/1 takes care of #4,

I am not sure how to deal with #2 and #5...

Serge