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

WARNING: фоновая информация довольно длинная. Перейдите к нижней части, если вы считаете, что вам нужен вопрос, прежде чем справочная информация. Цените время, которое это займет!

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

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

$ 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}]).

Эй, это прекрасно работает!

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

$ 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}]]).

Конечно, это тоже было просто. Теперь вот хитрые вещи ....

Let's say that you are taking daily backups. And you mnesia database server dies and you are forced to replace the hardware. If you want to restore the DB as-is then you need to name the NEW hardware with the same name that it had previously and you also need to name the nodes the same. if you want to change the name of the hardware and/or the node()... or you want to restore on a different machine, then you need to go through the node_change process. (described here and in the mnesia docs)

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

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

{atomic,[]}

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

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

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

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

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

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

Спрашивается немного по-другому: Как восстановить базу данных mnesia с репликацией нескольких узлов () на одном узле ()?