Mnesia Fragmentation and Replication: Resulting Availability and Reliability

Question

After resolving the question I recently asked about mnesia fragmentation , I still have a number of problems. Consider the following scenario (the question I ask is based on the following below):

You have a corporate data application that should be highly available in your enterprise. If for some reason the internal source of information is disconnected, corporate applications should switch to fetching data from the recovery center that has been deleted (deleted).

You have decided that the database will be replicated to two nodes within the enterprise
(designated as Side B A and Side B B ). These two run on separate equipment, but are interconnected, for example, Fast Ethernet or optical channel .
Logically, you create a tunnel or secure connection between the two two Mnesia DBs. Two (A and B) should have the same copy of data and be constantly synchronized.

Now, meanwhile, the recovery center should also have the same copy of the data in synchronization for the whole time in case local access to the data is disabled due to an attack or hardware failure. Thus, the same database schema must be replicated at 3 sites ( Side A , Side B and recovery center ).

Now, within the enterprise, an application middleware is able to switch data requests between database sites. If A does not work, then without an application that implements it, the request is redirected to database B and so on. The middle tier can be configured for load balancing (query multiplexing) or for flexibility when using failure methods.

Further analysis :

  At Database / Schema creation time, all involved Nodes must be up and running 
  Mnesia.  To achieve this, you create say: ' [e-mail] ' , 
  ' [e-mail] ' and finally, ' [e-mail] '

Now, when creating the table, you would like your mnesia tables to be fragmented. Therefore, you select the following options:

  n_disc_only_copies =: = number of nodes involved in the pool =: = 3
 Reason: You are following the documentation that this parameter regulates how 
  many disc_only_copies replicas that each fragment should have. 
  So you want each table to have each of its fragments on each mnesia Node. 
  node_pool =: = all nodes involved =: = [' [e-mail] ', 
  ' [e-mail] ', 
  ' [e-mail] ']

Then all your tables are created based on the following layout

  Nodes = [
                 ' [e-mail] ',
                 ' [e-mail] ',
                 ' [e-mail] '
             ],
     No_of_fragments = 16,
     {atomic, ok} = mnesia: create_table ( TABLE_NAME , [
                     {frag_properties, [
                         {node_pool, Nodes},
                         {n_fragments, No_of_fragments},
                         {n_disc_only_copies, length (Nodes)}]
                     },
                     {index, []},
                     {attributes, record_info (fields, RECORD_NAME_HERE )}]
                 ),

NOTE. In the syntax above, RECORD_NAME_HERE cannot be a variable in reality, since the records must be known at compile time with Erlang. From the installation, you will see that for each table, each fragment, say table_name_frag2 , appears in each Node file system.

Problems and questions :
After the above, your first start of the database is fine, since mnesia works on all nodes. Several problems begin to appear as the application launches and are listed below:

• Suppose you decide that all records are first checked on DB Side A , and if side A is not available at that moment, the call is re-checked on DB Side B and so on at the recovery center , and if the call does not return on all three database nodes , then the average level of the average application network reports that the database servers are unavailable (this decision could be affected by the fact that if you allow applications to accidentally write your mnesia replicas, it may result in inconsistent database errors if your mnesia nodes lose the network connection each other, but the records are made for each of them by different Erlang applications. If you decide to have master_nodes , then you risk losing data). Therefore, by behavior you force DB Side A be a master. This leads to the fact that other database nodes remain inactive all the time while DB Side A launched and works like many queries with a side A hit, and it does not drop, no query hits side B and the recovery center in general .

• When starting up, Mnesia should usually see all involved nodes (mnesia should work on all involved nodes) so that it can carry out its negotiations and consistency checks. This means that if mnesia falls on all nodes, mnesia must run on all nodes before it can fully initialize and load tables. Even worse, if Erlang VM dies with Mnesia on a remote site. Well, a few tweaks and scripts here and there can help reboot the entire virtual machine plus scheduled applications if it goes down.

To shorten the long story, let me move on to the questions.

Questions

• What would the database administrator do if mnesia generated inconsistent_database, starting to run database behind a partitioned network events inconsistent_database, starting to run database behind a partitioned network , in a situation where installing the mnesia master node undesirable (due to fear of data loss)?

• What is the result of the mnesia inconsistent_database, starting to run database behind a partitioned network event inconsistent_database, starting to run database behind a partitioned network regarding my application? What if I do not respond to this event and let everything continue as they are? Am I losing data?

• In large mnesia clusters, what can be done if Mnesia goes down with Erlang VM on a remote site? Are there any known good ways to automatically solve this situation?

• A time when one or two nodes are unavailable due to network problems or failures, and mnesia on the surviving Node reports that this file does not exist, especially in cases where you have indexes . So, at runtime, what will be the behavior of my application if some replicas are downgraded? Could you advise me to have a Node master inside the mnesia cluster?

As you answer the above questions, you can also highlight on the layout described at the beginning, regardless of whether it ensures availability. You can share your experiences with mnesia fragmented and replicated databases. Regarding the related (quoted) question at the very beginning of this text, provide alternative parameters that can provide greater reliability when creating the database, for example, in terms of number of fragments, operating system dependencies, Node pool size, table copy types, etc. .