ADVERTENCIA: La información de fondo es bastante larga. Salte a la parte inferior si cree que necesita la pregunta antes de la información de fondo. ¡Aprecie el tiempo que esto va a tomar!

He estado en toda la web (lea Google) y no he encontrado una buena respuesta. SÍ, hay muchos enlaces y referencias a la documentación de Mnesia en el sitio erlang.org, pero incluso esos enlaces tienen la versión de itis.

Entonces, en el caso más simple donde el nodo () al que está conectado actualmente es el mismo que el propietario del conjunto de tablas, entonces la copia de seguridad / restauración va a funcionar. Por ejemplo:

<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>

Hey esto funciona muy bien!

Sin embargo, si la base de datos se está ejecutando en un nodo remoto () o un nodo remoto () en un acoplamiento remoto, entonces debe iniciar la copia de seguridad de esta manera:

<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>

Por supuesto esto también era simple. Ahora aquí están las cosas difíciles ...

Digamos que usted está tomando copias de seguridad diarias. Y su servidor de base de datos mnesia muere y se ve obligado a reemplazar el hardware. Si desea restaurar la base de datos tal como está, debe asignar un nombre al NUEVO hardware con el mismo nombre que tenía anteriormente y también debe asignar el mismo nombre a los nodos.Si desea cambiar el nombre del hardware y / o el nodo () ... o si desea restaurar en una máquina diferente, debe pasar por el proceso de cambio de nodo. (descritoaquí y en la mnesia docs)

Pero aquí es donde las cosas se complican. Mientras que mis conocidos, que son expertos en erlang y mnesia, sugieren que la réplica de mnesia es muy defectuosa y que no debería usarla (actualmente no hay alternativas que conozca y cuáles son las posibilidades de que vaya a implementar una mejor versión; probable)

Así que tienes dos nodos () que están replicando tablas basadas en RAM y en disco. Ha estado manteniendo una política de hacer copias de seguridad de la base de datos con regularidad con la copia de seguridad estándar utilizando el método de respaldo predeterminado. Y un día un gerente le pide que verifique las copias de seguridad. Solo cuando intentas restaurar la base de datos obtienes:

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

Y de acuerdo con la documentación, esto significa que no hubo errores ... y, sin embargo, no se restauraron las tablas.

Al no querer ejecutar el procedimiento change_node, recuerda que el nodo () y el nombre de host deben coincidir, por lo que cambia el nombre de host y el parámetro -sname para que coincida con la máquina donde se realizó la copia de seguridad de los datos. Esta vez sin embargo te sale un error extraño:

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

Aún sin querer ejecutar el procedimiento change_node, cloné rápidamente la restauración de mi servidor para tener dos máquinas similares. Nombro entonces apropiadamente para que coincida con los servidores de producción. Y empiezo el proceso de restauración. ¡Eureka! Ahora tengo datos reales de trabajo en los servidores de restauración.

Me gustaría decir que este fue el final del camino ... pero todavía no he hecho una pregunta y que el punto de SO ... ¿aquí está?

PREGUNTA: Si quiero restaurar una copia de seguridad que se tomó de un grupo de nodos mnesia replicados, ¿cómo modifico el archivo (similar al procedimiento change_node) para que los otros nodos sean ignorados o eliminados de la copia de seguridad?

Preguntado de forma ligeramente diferente: ¿Cómo restauro una base de datos mnesia de múltiples nodos () en un solo nodo ()?