Sysinfo Sql Backup Recovery

[Rosalia Kemme]

IfMnesia malfunctions, system information is dumped to fileMnesiaCore.Node.When. The type of system information contained in this filecan also be generated with the function mnesia_lib:coredump(). If a Mnesiasystem behaves strangely, it is recommended that a Mnesia core dump file isincluded in the bug report.

Tables of type ram_copies are by definition stored in memory only. However,these tables can be dumped to disc, either at regular intervals or before thesystem is shut down. The functionmnesia:dump_tables(TabList) dumps all replicas of aset of RAM tables to disc. The tables can be accessed while being dumped todisc. To dump the tables to disc, all replicas must have the storage typeram_copies.

A checkpoint is a transaction consistent state that spans over one or moretables. When a checkpoint is activated, the system remembers the current contentof the set of tables. The checkpoint retains a transaction consistent state ofthe tables, allowing the tables to be read and updated while the checkpoint isactive. A checkpoint is typically used to back up tables to external media, butthey are also used internally in Mnesia for other purposes. Each checkpoint isindependent and a table can be involved in several checkpoints simultaneously.

Each table retains its old contents in a checkpoint retainer. For performancecritical applications, it can be important to realize the processing overheadassociated with checkpoints. In a worst case scenario, the checkpoint retainerconsumes more memory than the table itself. Also, each update becomes slightlyslower on those nodes where checkpoint retainers are attached to the tables.

For each table, it is possible to choose if there is to be one checkpointretainer attached to all replicas of the table, or if it is enough to have onlyone checkpoint retainer attached to a single replica. With a single checkpointretainer per table, the checkpoint consumes less memory, but it is vulnerable tonode crashes. With several redundant checkpoint retainers, the checkpointsurvives as long as there is at least one active checkpoint retainer attached toeach table.

Checkpoints can be explicitly deactivated with the functionmnesia:deactivate_checkpoint(Name), whereName is the name of an active checkpoint. This function returns ok ifsuccessful or error, Reason if there is an error. All tables in a checkpointmust be attached to at least one checkpoint retainer. The checkpoint isautomatically deactivated by Mnesia, when any table lacks a checkpointretainer. This can occur when a node goes down or when a replica is deleted. Usearguments min and max (described in the following list) to control thedegree of checkpoint retainer redundancy.

The response shows that the file FALLBACK.BUP has been created. This is calleda backup file, and it contains an initial schema. If more than one node in thefunction mnesia:create_schema/1 had been specified, identical backup fileswould have been created on all nodes.

The schema in the backup file FALLBACK.BUP has been used to generate the fileschema.DAT. Since there are no other disc resident tables than the schema, noother data files were created. The file FALLBACK.BUP was removed after thesuccessful "restoration". You also see some files that are for internal use byMnesia.

When starting Mnesia, a .LOG file called LATEST.LOG is created and placedin the database directory. This file is used by Mnesia to log disc-basedtransactions. This includes all transactions that write at least one record in atable that is of storage type disc_copies or disc_only_copies. The file alsoincludes all operations that manipulate the schema itself, such as creating newtables. The log format can vary with different implementations of Mnesia. TheMnesia log is currently implemented in the standard library moduledisk_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 inthe log and place the records in the corresponding .DAT, .DCD, and .DCLdata files. For example, if the operation "write record foo, 4, elvis, 6" islisted 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 movedto the .DCD file. The dumping operation can be time consuming if the log islarge. Notice that the Mnesia system continues to operate during log dumps.

By default Mnesia either dumps the log whenever 1000 records have been writtenin the log or when three minutes have passed. This is controlled by the twoapplication parameters -mnesia dump_log_write_threshold WriteOperations and-mnesia dump_log_time_threshold MilliSecs.

The directory listing also contains one .DAT file, which contains the schemaitself, contained in the schema.DAT file. The DAT files are indexed files,and it is efficient to insert and search for records in these files with aspecific key. The .DAT files are used for the schema and fordisc_only_copies tables. The Mnesia data files are currently implemented inthe standard library module dets in STDLIB.

All operations that can be performed on dets files can also be performed onthe Mnesia data files. For example, dets contains the functiondets:traverse/2, which can be used to view the contents of a Mnesia DATfile. However, this can only be done when Mnesia is not running. So, to viewthe schema file, do as follows;

The DAT files must always be opened with option repair, false. Thisensures that these files are not automatically repaired. Without this option,the database can become inconsistent, because Mnesia can believe that thefiles were properly closed. For information about configuration parameterauto_repair, see the Reference Manual.

At startup, Mnesia loads tables to make them accessible for its applications.Sometimes Mnesia decides to load all tables that reside locally, and sometimesthe tables are not accessible until Mnesia brings a copy of the table fromanother node.

To understand the behavior of Mnesia at startup, it is essential to understandhow Mnesia reacts when it loses contact with Mnesia on another node. At thisstage, Mnesia cannot distinguish between a communication failure and a"normal" node-down. When this occurs, Mnesia assumes that the other node is nolonger running, whereas, in reality, the communication between the nodes hasfailed.

At startup, notice that all tables residing on nodes without a mnesia_downentry can have fresher replicas. Their replicas can have been updated after thetermination of Mnesia on the current node. To catch up with the latestupdates, transfer a copy of the table from one of these other "fresh" nodes. Ifyou are unlucky, other nodes can be down and you must wait for the table to beloaded on one of these nodes before receiving a fresh copy of the table.

Before an application makes its first access to a table,mnesia:wait_for_tables(TabList, Timeout) is to beexecuted to ensure that the table is accessible from the local node. If thefunction times out, the application can choose to force a load of the localreplica with mnesia:force_load_table(Tab) anddeliberately lose all updates that can have been performed on the other nodeswhile the local node was down. If Mnesia has loaded the table on another nodealready, or intends to do so, copy the table from that node to avoid unnecessaryinconsistency.

The allowed AccessMode of a table can be defined to be read_only orread_write. It can be toggled with the functionmnesia:change_table_access_mode(Tab, AccessMode)in runtime. read_only tables and local_content tables are always loadedlocally, as there is no need for copying the table from other nodes. Othertables are primarily loaded remotely from active replicas on other nodes if thetable has been loaded there already, or if the running Mnesia has decided toload the table there already.

This is normally a wise decision, but it can be disastrous if the nodes havebeen disconnected because of a communication failure, as the Mnesia normaltable load mechanism does not cope with communication failures.

When Mnesia loads many tables, the default load order is used. However, theload order can be affected, by explicitly changing property load_order for thetables, with the functionmnesia:change_table_load_order(Tab, LoadOrder).LoadOrder is by default 0 for all tables, but it can be set to any integer.The table with the highest load_order is loaded first. Changing the load orderis especially useful for applications that need to ensure early availability offundamental tables. Large peripheral tables are to have a low load order value,perhaps less than 0

If the application detects that there has been a communication failure that canhave caused an inconsistent database, it can use the functionmnesia:set_master_nodes(Tab, Nodes) to pinpointfrom which nodes each table can be loaded.

At startup, the Mnesia normal table load algorithm is bypassed and the tableis loaded from one of the master nodes defined for the table, regardless ofpotential mnesia_down entries in the log. Nodes can only contain nodes wherethe table has a replica. If Nodes is empty, the master node recovery mechanismfor the particular table is reset and the normal load mechanism is used at thenext restart.

The function mnesia:set_master_nodes(Nodes) setsmaster nodes for all tables. For each table it determines its replica nodes andstarts mnesia:set_master_nodes(Tab, TabNodes)with those replica nodes that are included in the Nodes list (that is,TabNodes is the intersection of Nodes and the replica nodes of the table).If the intersection is empty, the master node recovery mechanism for theparticular table is reset and the normal load mechanism is used at the nextrestart.

Determining what data to keep after a communication failure is outside the scopeof Mnesia. One approach is to determine which "island" contains most of thenodes. Using option majority,true for critical tables can be a way to ensurethat nodes that are not part of a "majority island" cannot update those tables.Notice that this constitutes a reduction in service on the minority nodes. Thiswould be a tradeoff in favor of higher consistency guarantees.

3a8082e126