ПРЕДУПРЕЖДЕНИЕ: фоновая информация довольно длинная. Пропустите к концу, если вы считаете, что вам нужен вопрос перед фоновым сообщением. Цените время, которое это займет!
Я был повсюду в Интернете (читал google), и я не нашел хорошего ответа. ДА, есть много ссылок и ссылок на документацию Mnesia на сайте erlang.org, но даже эти ссылки страдают от версии 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}]).
Эй, это отлично работает!
Однако, если база данных фактически запущена на удаленном node() или удаленном node() при удаленном спаривании, тогда вы должны инициировать резервное копирование следующим образом:
$ erl -sname mydbadmin
> rpc:call([email protected], mnesia, backup, ["/tmp/backup.bup"]).
> rpc:call([email protected], mnesia, restore, ["/tmp/backup.bup", [{default_op, recreate_tables}]]).
Конечно, это было просто. Теперь вот сложные вещи....
- Предположим, что вы ежедневно делаете резервные копии. И ваш сервер базы данных mnesia умирает, и вы вынуждены заменить оборудование. Если вы хотите восстановить DB как есть, вам нужно назвать новое оборудование с тем же именем, которое было ранее, и вам также нужно назвать узлы одинаковыми.
- Если вы хотите изменить имя аппаратного обеспечения и/или node()... или хотите восстановить на другом компьютере, вам необходимо пройти процесс node_change. (описано здесь и в документах mnesia)
Но здесь все усложняется. Хотя мои знакомые, которые являются экспертами erlang и mnesia, предполагают, что репликация mnesia сильно испорчена и что вы не должны ее использовать (в настоящее время нет альтернатив, о которых я знаю, и каковы шансы, что вы собираетесь использовать лучшую версию, а не вероятно)
Итак, у вас есть два узла(), которые реплицируют таблицы на основе бара и диска. Вы регулярно поддерживаете политику резервного копирования базы данных с помощью стандартной резервной копии с использованием BackupMod по умолчанию. И однажды менеджер попросит вас проверить резервные копии. Только при попытке восстановить базу данных вы получаете:
{atomic,[]}
И согласно документации это означает, что ошибок не было... и все же таблицы не были восстановлены.
Не желая запускать процедуру change_node, вы помните, что node() и имя хоста должны совпадать, чтобы вы изменили имя хоста и параметр -sname, чтобы он соответствовал машине, на которой были скопированы данные. На этот раз вы получите странную ошибку:
{aborted,{'EXIT',{aborted,{bad_commit,{missing_lock,[email protected]}}}}}
По-прежнему не желая запускать процедуру change_node, я быстро клонирую восстановление своего сервера, чтобы у меня было две аналогичные машины. Я называю тогда подходящим образом, чтобы соответствовать производственным серверам. И я начинаю процесс восстановления. Эврика! Теперь у меня есть реальные рабочие данные на серверах восстановления.
Я хотел бы сказать, что это был конец дороги... но я еще не задал вопрос и что точка SO.... так вот оно?
ВОПРОС: , если я хочу восстановить резервную копию, взятую из кластера реплицированных узлов mnesia, как мне изменить файл (аналогично процедуре change_node), чтобы другие узлы были либо игнорируется или удаляется из резервной копии?
Задано несколько иначе: Как восстановить базу данных mixedia с репликацией-multi- node() на одном node()?