Erlangmnesia database backup and Restoration

When a database is used, database backup is performed. When a database fails to be started due to a serious error or data loss, data can be restored in a timely and effective manner. This article first introduces how to back up and restore the ErlangMnesia database, and then discusses the backup mechanism of mnesia in two aspects: Backup and rollback. After the backup database is started in Mnesia, you can use

When a database is used, database backup is performed. When a database fails to be started due to a serious error or data loss, data can be restored in a timely and effective manner. This article first introduces how to back up and restore the Erlang Mnesia database, and then discusses the backup mechanism of mnesia in two aspects: Backup and rollback. After the backup database is started in Mnesia, you can use

When a database is used, database backup is performed. When a database fails to be started due to a serious error or data loss, data can be restored in a timely and effective manner. This article first introduces how to back up and restore the Erlang Mnesia database, and then discusses the backup mechanism of mnesia in two aspects: Backup and rollback.

Back up database

After Mnesia is started, you can use mnesia: backup () for backup. function prototype:

Mnesia: backup (Opaque [, BackupMod])-> OK | {error, Reason}

# Before calling the API, make sure that mnesia runs normally. The stored directory contains mnesia: backup ("d:/backup. log ").

Restore database

After mnesia is started, you can use mnesia: restore () for restoration. function prototype:

Mnesia: restore (Opaque, Args)-> {atomic, RestoredTabs} | {aborted, Reason}

All tables related to the restoration process are written with locks. data can be restored without restarting mnesia.

# Before calling the API, make sure that mnesia runs normally. mnesia: restore ("d:/backup. log", []).

Well, if you only know how to back up and restore the mnesia database, it's over.

If you want to learn more about the backup mechanism of mnesia, continue.

/******************/Author: The Tree blog does not blossom: blog.csdn.net/mycwq/******* relentless copy *********/

Backup and rollback

The following functions are used to back up data and install backup for rollback:

# Execute a table backup mnesia: backup_checkpoint (Name, Opaque [, BackupMod]) contained in the checkpoint. # activate a new checkpoint that overwrites all Mnesia tables and perform a backup (the backup is executed with maximum redundancy) mnesia: backup (Opaque [, BackupMod]) # backup dump, creates a new backup from an existing backup. You can copy backups between different media. Mnesia: traverse_backup (Source, [SourceMod,] Target, [TargetMod,] Fun, Ac) # recover from an existing backup table mnesia: restore (Opaque, Args) # Install rollback, restart from an existing backup, and reload the database table. Mnesia: install_fallback (Opaque, [Mod]) # Remove the previously installed rollback file mnesia: uninstall_fallback ()

Mnesia: the internal implementation of the backup () process is divided into the following three steps:

1. Create a checkpoint: mnesia: activate_checkpoint/1
2. perform backup: mnesia: backup_checkpoint/3
3. Disable checkpoint: mnesia: deactivate_checkpoint/1

In contrast, mnesia: the backup method is brutal, and the maximum redundant backup is performed, that is, the backup of all data, including all copies ). When the data volume is large, the restoration process takes a long time. If you only need to back up some important table data, you can create a checkpoint by yourself.

Create a checkpoint

Erlang explains the checkpoint concept as follows:

A checkpoint is a consistent view of the system. A checkpoint can be activated on a set of tables. this checkpoint can then be traversed and will present a view of the system as it existed at the time when the checkpoint was activated, even if the tables are being or have been manipulated.

Generally, checkpoints are used to maintain system visualization. A checkpoint is equivalent to a system image. During the backup process, even if the data changes, the backup content is not affected.

The checkpoint is created using the mnesia: activate_checkpoint function. erlang starts the mnesia_checkpoint process on all nodes, which is supervised by the mnesia_checkpoint_sup process. For more information, see mnesia_checkpoint: init/1.

The mnesia_checkpoint process monitors data changes. The main actions are add_retainer, del_retainer, add_copy, del_copy, and change_copy.

Function prototype: mnesia: activate_checkpoint (Args)-> {OK, Name, Nodes} | {error, Reason}

Parameter description:

The Args parameter is a list of the following tuples:

Parameter	Description	Default Value
{Name, Name}	The Name is the checkpoint Name, which must be unique among the associated nodes. This name can be used repeatedly when the checkpoint is stopped. You do not need to set it. The system automatically generates a unique name.	{Erlang: now (), erlang: node ()}
{Max, MaxTabs}	MaxTabs tells erlang which tables require maximum Redundancy backup, that is, all copies are also backed up. The default value is [].	[]
{Min, MinTabs}	MinTabs tells erlang which tables require minimal redundant backup, that is, only one copy is backed up. We recommend that you store copies on local nodes. Default Value []	[]
{Allow_remote, Bool}	If Bool is set to false, it means that all the connection holders must be local. If any of the tables involved does not belong to a local node, the checkpoint cannot be created successfully. If Bool is true, it is allowed to be allocated to any node.	True
{Ram_overrides_dump, Bool}	Applies only to ram_copies. Select the mode you want to back up. "true" indicates that the checkpoint is recorded when the recent record is submitted to RAM. "false" indicates that the record is recorded to the checkpoint only when it is dumped to the DAT file. Note that the RAM record is the data when the application is running, and the DAT record is only the record to be loaded when mnesia starts. The default value is false.	False

Execute backup

Let's take a look at erlang's explanation of the content:

The tables are backed up to external media using the backup module BackupMod. tables with the local contents property is being backed up as they exist on the current node. backupMod is the default backup callback module obtained by mnesia: system_info (backup_module ).

In general, erlang backs up local table data and table attributes during backup, and can back up data to other storage media by using the BackupMod parameter.

Function prototype: mnesia: backup_checkpoint (Name, Opaque [, BackupMod])-> OK | {error, Reason}

Parameter description:

Opaque parameter: this parameter is passed in as the BackupMod parameter of the backup module. If no backup module is specified, this parameter indicates the local file name.

Stop checkpoint:

A simple understanding is to delete the previously created checkpoint.

Function prototype: mnesia: deactivate_checkpoint (Name)-> OK | {error, Reason}

Pay attention to the following issues. The checkpoint may be disabled even if mnesia: deactivate_checkpoint/1 is not called. Erlang explains this function as follows:

The checkpoint is automatically deactivated when some of the tables involved have no retainer attached to them. This may happen when nodes go down or when a replica is deleted.

Generally, when any table involved does not have a retainer, the checkpoint is automatically disabled. If a node fails or the data copy is deleted, the checkpoint may be disabled.

The following is a manual backup process:

4>  {ok, Name, _} = mnesia:activate_checkpoint( [ { max, [tb_message] } ] ).{ok,{{1387,505130,66000},nonode@nohost},[nonode@nohost]}5> mnesia:backup_checkpoint( Name, "d:/backup.log", [] ).ok6> mnesia:deactivate_checkpoint( Name ).ok

Restore data

Used to restore the data that has been backed up before. All Tables related to the restoration process are written in locks. data can be restored without the need to restart mnesia.

Function prototype:

Mnesia: restore (Opaque, Args)-> {atomic, RestoredTabs} | {aborted, Reason}

Parameter description:

Opaque parameter: this parameter is passed in as the BackupMod parameter of the backup module. If no backup module is specified, this parameter indicates the local file name.

The Args parameter is a list of the following tuples:

Parameter	Description
{Module, BackupMod}	BackupMod is used to process and recover data using a custom module. If this parameter is ignored, the system module is used.
{Skip_tables, TabList}	TabList tells erlang which tables do not need to be restored
{Clear_tables, TabList}	TabList tells erlang which tables need to clear all records in the table before restoring data. Note: The table will not be deleted here, but all records will be restored.
{Keep_tables, TabList}	TabList tells erlang which tables will not be cleared before data recovery, and the records in the backup will be added to the table. Note: The table will not be deleted here, but all new records will be added.
{Recreate_tables, TabList}	TabList tells erlang which tables need to be re-created before data recovery. These tables will be deleted and then rebuilt. Note: The table will be deleted here.
{Default_op, Operation}	Operation Parameter Values: skip_tables, clear_tables, keep_tables or recreate_tables. This parameter is used to specify the default behavior of erlang to restore tables. That is to say, tables that do not specify the restoration method will be processed in this way. If this parameter is not set, the default value is clear_tables.

Rollback

First, we need to clarify what is rollback, why is rollback used, and when is rollback used?

Let's take a look at erlang's explanation of the content:

This function is used to install a backup as fallback. the fallback will be used to restore the database at the next start-up. installation of fallbacks requires Erlang to be up and running on all the involved nodes, but it does not matter if Mnesia is running or not. the installation of the fallback will fail if the local node is not one of the disc resident nodes in the backup.

Rollback is used to restore the database when the next system is started. That is to say, after the rollback is installed, the system does not restore data immediately, but waits for mnesia to recover data after restart.

Why is rollback required? The previous restore method (restore) is executed as a separate transaction. All table write locks related to the restoration process. If the database is too large, other programs may be affected or cannot be restored successfully. In this case, the database must be restored by installing a rollback and then restarted.

Another scenario is to use rollback to restore data when mnesia cannot be started. When mnesia crashes, that is, the schema is damaged or the data is seriously incorrect, mnesia cannot be started, and the original recovery method (restore) cannot be used.

Rollback is a distributed operation, either performed on all database nodes or not. The installation of rollback requires that all database-related nodes in Erlang be started and run, even if the Mnesia process is not running.

Function prototype:

Mnesia: install_fallback (Opaque, Args)-> OK | {error, Reason}

Opaque parameter: this parameter is passed in as the BackupMod parameter of the backup module. If no backup module is specified, this parameter indicates the local file name.

The Args parameter is a list of the following tuples:

Parameter	Description
{Module, BackupMod}	BackupMod is used to process and recover data using a custom module. If this parameter is ignored, the system module is used.
{Scope, Scope}	Scope can be a global or local node ). The default value is global. Which node is the disk storage type depends on the imported backup file.
{Mnesia_dir, AlternateDir}	This parameter is valid when the scope parameter is local. Generally, the installation of rollback is based on the default directory of mnesia. You can also configure AlternateDir to modify the rollback installation address. After the rollback is installed, this directory becomes a valid mnesia directory. This parameter item is dangerous. Please use it with caution. Otherwise, Database Inconsistency may occur.

Uninstall rollback

Give erlang an opportunity to explain:

This function is used to de-install a fallback before it has been used to restore the database. this is normally a distributed operation that is either stored med on all nodes with disc resident schema or none. uninstallation of fallbacks requires Erlang to be up and running on all involved nodes, but it does not matter if Mnesia is running or not. which nodes that are considered as disc-resident nodes is determined from the schema info in the local fallback.

This function is used to remove rollback before the database is restored.

Detaching and rollback is also a distributed operation, either performed on all database nodes or not. The installation of rollback requires that all database-related nodes in Erlang be started and run, even if the Mnesia process is not running.

Function prototype:

Mnesia: uninstall_fallback (Args)-> OK | {error, Reason}

For more information about Args parameters, see Args parameters for rollback.