AVISO: as informações de segundo plano são bem longas. Pule para o final se você acha que precisa da pergunta antes da informação de segundo plano. Aprecie o tempo que isso vai levar!

Eu estive em toda a web (leia o google) e não encontrei uma boa resposta. Sim, há muitos links e referências à documentação da Mnesia no site erlang.org, mas mesmo esses links sofrem com a versão-itis.

Portanto, no caso mais simples em que o node () no qual você está conectado atualmente é o mesmo que o proprietário do conjunto de tabelas, o backup / restauração irá funcionar. Por exemplo:

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

Ei isso funciona muito bem!

No entanto, se o banco de dados estiver realmente em execução em um nó remoto () ou em um nó remoto () em um acoplamento remoto, será necessário iniciar o backup dessa maneira:

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

Claro que isso também era simples. Agora aqui estão as coisas complicadas ....

Digamos que você esteja fazendo backups diários. E você mnias servidor de banco de dados morre e você é forçado a substituir o hardware. Se você quiser restaurar o banco de dados como está, será necessário nomear o NOVO hardware com o mesmo nome anterior e também será necessário nomear os nós da mesma forma.Se você quiser alterar o nome do hardware e / ou o nó () ... ou desejar restaurar em uma máquina diferente, será necessário passar pelo processo node_change. (descritoAqui e na mnesia docs)

Mas aqui é onde as coisas ficam complicadas. Enquanto conhecidos meus, que são experts em erlang e mnesia, sugerem que a replicação da mnesia é severamente falha e que você não deve usá-la (atualmente não há alternativas que eu saiba e quais são as chances de você implementar uma versão melhor; provável)

Portanto, você tem dois nós () que estão replicando tabelas baseadas em RAM e disco. Você tem mantido uma política de fazer backup do banco de dados regularmente com o backup padrão usando o BackupMod padrão. E um dia um gerente pede que você verifique os backups. Apenas quando você tenta restaurar o banco de dados que você recebe:

<code>{atomic,[]}
</code>

E de acordo com a documentação, isso significa que não houve erros ... e, no entanto, nenhuma tabela foi restaurada.

Não querendo executar o procedimento change_node, você deve lembrar que o nó () e o nome do host devem corresponder, portanto, você altera o nome do host e o parâmetro -sname para corresponder à máquina na qual os dados foram submetidos a backup. Desta vez, no entanto, você recebe um erro estranho:

<code>{aborted,{'EXIT',{aborted,{bad_commit,{missing_lock,mydatabase@otherhost}}}}}
</code>

Ainda não querendo executar o procedimento change_node eu clonei rapidamente o meu servidor para que eu tenha duas máquinas similares. Eu nomeio então apropriadamente para combinar os servidores de produção. E eu começo o processo de restauração. Eureka! Agora tenho dados reais de trabalho nos servidores de restauração.

Eu gostaria de dizer que este foi o fim da estrada ... mas eu não fiz uma pergunta ainda e que o ponto de SO .... então aqui está?

QUESTÃO: se eu quiser restaurar um backup que foi obtido de um cluster de mnesia replicated nodes, como modifico o arquivo (semelhante ao procedimento change_node) para que os outros nós sejam ignorados ou removidos do backup?

Questionado de forma ligeiramente diferente: Como restaurar um banco de dados mnesia replicado com vários nós em um único nó ()?