WARNUNG: Die Hintergrundinformationen sind ziemlich lang. Gehen Sie nach unten, wenn Sie der Meinung sind, dass Sie die Frage vor den Hintergrundinformationen benötigen. Schätzen Sie die Zeit, die das dauern wird!

Ich war im ganzen Web unterwegs (lese Google) und habe keine gute Antwort gefunden. JA, es gibt viele Links und Verweise auf die Mnesia-Dokumentation auf der Website erlang.org, aber auch diese Links leiden unter version-itis.

Im einfachsten Fall, in dem der Knoten (), mit dem Sie gerade verbunden sind, derselbe ist wie der Eigentümer des Tabellensatzes, wird die Sicherung / Wiederherstellung ausgeführt. Zum Beispiel:

<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 das klappt super!

Wenn die Datenbank jedoch tatsächlich auf einem Remote-Knoten () oder einem Remote-Knoten () auf einer Remote-Verknüpfung ausgeführt wird, müssen Sie die Sicherung folgendermaßen initiieren:

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

Das war natürlich auch einfach. Nun, hier sind die kniffligen Dinge ...

Angenommen, Sie erstellen täglich Backups. Und Sie Mnesia-Datenbankserver stirbt und Sie sind gezwungen, die Hardware zu ersetzen. Wenn Sie den DB wie er ist wiederherstellen möchten, müssen Sie die NEUE Hardware mit demselben Namen wie zuvor benennen und die Knoten ebenfalls mit demselben Namen versehen.Wenn Sie den Namen der Hardware und / oder des Knotens () ändern möchten oder auf einem anderen Computer wiederherstellen möchten, müssen Sie den Prozess node_change ausführen. (beschriebenHier und in der Mnesia docs)

Aber hier wird es kompliziert. Bekannte von mir, die Experten für Erlang und Mnesia sind, schlagen vor, dass die Replikation von Mnesia schwerwiegende Fehler aufweist und dass Sie sie nicht verwenden sollten wahrscheinlich)

Sie haben also zwei Nodes (), die RAM- und Disc-basierte Tabellen replizieren. Sie haben eine Richtlinie zum regelmäßigen Sichern der Datenbank mit der Standardsicherung unter Verwendung des Standard-BackupMod beibehalten. Und eines Tages bittet Sie ein Manager, die Backups zu überprüfen. Nur wenn Sie versuchen, die Datenbank wiederherzustellen, erhalten Sie:

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

Und laut Dokumentation bedeutet dies, dass keine Fehler aufgetreten sind ... und dennoch keine Tabellen wiederhergestellt wurden.

Wenn Sie die Prozedur change_node nicht ausführen möchten, müssen Sie daran denken, dass node () und hostname übereinstimmen müssen, damit Sie den Hostnamen und den Parameter -sname an den Computer anpassen, auf dem die Daten gesichert wurden. Diesmal erhalten Sie jedoch einen seltsamen Fehler:

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

Ich möchte die change_node-Prozedur immer noch nicht ausführen. Ich klone schnell und stelle meinen Server wieder her, sodass ich zwei ähnliche Computer habe. Ich benenne dann passend zu den Produktionsservern. Und ich beginne den Wiederherstellungsprozess. Eureka! Ich habe jetzt echte Arbeitsdaten auf den Wiederherstellungsservern.

Ich würde gerne sagen, dass dies das Ende des Weges war ... aber ich habe noch keine Frage gestellt und dass der Sinn von SO ... also hier ist es?

FRAGE: Wie ändere ich die Datei (ähnlich der Prozedur change_node), damit die anderen Knoten entweder ignoriert oder aus der Sicherung entfernt werden, wenn ich eine Sicherung wiederherstellen möchte, die aus einem Cluster replizierter Mnesia-Knoten stammt?

Etwas anders gefragt: Wie kann ich eine replizierte Multi-Node () -Mnesia-Datenbank auf einem einzelnen Knoten () wiederherstellen?