Как правильно сделать резервную копию/восстановить базу данных mnesia?

ПРЕДУПРЕЖДЕНИЕ: справочная информация довольно длинная. Пропустите вниз, если считаете, что вам нужен вопрос перед справочной информацией. Цените время, которое это займет возьми!

Я облазил весь интернет (почитай гугл) и не нашел хорошего ответа.ДА, на сайте erlang.org полно ссылок и ссылок на документацию Mnesia, но даже эти ссылки страдают из version-itis.

Таким образом, в простейшем случае, когда node(), к которому вы в данный момент подключены, совпадает с владельцем набора таблиц, тогда резервное копирование/восстановление будет работать.Например:

$ erl -sname mydatabase

> mnesia:start().
> mnesia:create_schema(...).
> mnesia:create_table(...).
> mnesia:backup("/tmp/backup.bup").
> mnesia:restore("/tmp/backup.bup", [{default_op, recreate_tables}]).

Hey это прекрасно работает!

Однако, если база данных на самом деле работает на удаленном узле() или удаленном узле() на удаленном соединении, вам нужно инициировать резервное копирование следующим образом:

$ erl -sname mydbadmin

> rpc:call(mydatabase@host, mnesia, backup, ["/tmp/backup.bup"]).
> rpc:call(mydatabase@host, mnesia, restore, ["/tmp/backup.bup", [{default_op, recreate_tables}]]).

Конечно, это тоже было просто .А теперь самое сложное...

• Допустим, вы делаете ежедневные резервные копии, и у вас умирает сервер базы данных mnesia, и вы вынуждены заменять оборудование. ре. Если вы хотите восстановить БД как есть, вам нужно назвать НОВОЕ оборудование тем же именем, что и раньше, и вам также нужно назвать узлы так же.
• если вы хотите изменить имя оборудования и/или node()... или вы хотите восстановить на другой машине, вам нужно пройти процесс node_change.(описано здесьи в документах mnesia)

Но здесь все усложняется. В то время как мои знакомые, которые являются экспертами по erlang и mnesia, предполагают, что репликация mnesia имеет серьезные недостатки и что вам не следует ее использовать (в настоящее время нет никаких альтернатив, о которых я знаю, и каковы шансы, что вы собираетесь реализовать лучшую версию; не скорее всего)

Итак, у вас есть два узла(), которые реплицируют таблицы на основе оперативной памяти и диска. Вы придерживаетесь политики регулярного резервного копирования базы данных с помощью стандартного резервного копирования с использованием BackupMod по умолчанию. И однажды менеджер просит вас проверить резервные копии. Только при попытке восстановить базу получается:

{atomic,[]}

А по документации это означает, что ошибок не было... и тем не менее таблицы не восстанавливались.

Не желая запускать процедуру change_node, вы помните, что node() и имя хоста должны совпадать, поэтому вы меняете имя хоста и параметр -sname, чтобы они соответствовали машине, на которой были созданы резервные копии данных. Однако на этот раз вы получаете странную ошибку:

{aborted,{'EXIT',{aborted,{bad_commit,{missing_lock,mydatabase@otherhost}}}}}

Все еще не желая запускать процедуру change_node, я быстро клонирую восстановление своего сервера, чтобы у меня было две похожие машины. Затем я называю это соответствующим образом, чтобы соответствовать производственным серверам. И начинаю процесс восстановления. Эврика! Теперь у меня есть реальные рабочие данные на серверах восстановления.

Я хотел бы сказать, что это был конец пути... но я еще не задал вопрос и что смысл ТАК....так вот?

ВОПРОС:если я хочу восстановить резервную копию, которая была взята из кластера реплицированных узлов mnesia, как мне изменить файл (аналогично процедуре change_node), чтобы другие узлы либо игнорировались, либо удалялись из резервная копия?

Несколько иной вопрос: как восстановить базу данных mnesia с репликацией нескольких узлов() на одном узле()?