OSTRZEŻENIE: informacje o tle są dość długie. Przejdź na dół, jeśli uważasz, że potrzebujesz pytania przed informacjami w tle. Doceń czas, jaki to zajmie!

Byłem w sieci (czytaj google) i nie znalazłem dobrej odpowiedzi. TAK, istnieje wiele linków i odniesień do dokumentacji Mnesii na stronie erlang.org, ale nawet te linki cierpią z powodu wersji-itis.

Tak więc w najprostszym przypadku, w którym węzeł (), z którym aktualnie jesteś połączony, jest taki sam jak właściciel zestawu tabel, wówczas kopia zapasowa / przywracanie będzie działać. Na przykład:

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

Hej, to działa świetnie!

Jeśli jednak baza danych faktycznie działa na zdalnym węźle () lub zdalnym węźle () na zdalnym łączeniu, musisz zainicjować kopię zapasową w ten sposób:

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

Oczywiście to też było proste. Teraz są trudne rzeczy ....

Powiedzmy, że robisz codzienne kopie zapasowe. A serwer bazy danych Mnesia umiera i jesteś zmuszony do wymiany sprzętu. Jeśli chcesz przywrócić bazę danych jako taką, musisz nazwać NOWY sprzęt o tej samej nazwie, która była poprzednio, a także musisz nazwać te same węzły.Jeśli chcesz zmienić nazwę sprzętu i / lub węzła () ... lub chcesz przywrócić na innym komputerze, musisz przejść przez proces node_change. (opisanetutaj iw dokumentach mnesia)

Ale tutaj sprawy się komplikują. Podczas gdy moi znajomi, którzy są ekspertami erlang i mnesia sugerują, że replikacja mnesii jest poważnie wadliwa i że nie powinieneś jej używać (obecnie nie ma alternatyw, które znam i jakie są szanse, że zamierzasz wdrożyć lepszą wersję; nie prawdopodobne)

Mamy więc dwa węzły (), które replikują tabele oparte na pamięci RAM i dyskach. Zachowujesz zasadę regularnego tworzenia kopii zapasowej bazy danych przy użyciu standardowej kopii zapasowej przy użyciu domyślnego BackupMod. A pewnego dnia menedżer prosi o sprawdzenie kopii zapasowych. Dopiero gdy spróbujesz przywrócić bazę danych, otrzymasz:

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

I zgodnie z dokumentacją oznacza to, że nie było błędów ... a mimo to nie przywrócono żadnych tabel.

Nie chcąc uruchamiać procedury change_node, pamiętaj, że węzeł () i nazwa hosta muszą być zgodne, aby zmienić nazwę hosta i parametr -sname, aby dopasować maszynę, na której dane zostały zarchiwizowane. Tym razem jednak pojawia się dziwny błąd:

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

Nadal nie chcę uruchamiać procedury change_node. Szybko klonuję przywracanie mojego serwera, dzięki czemu mam dwie podobne maszyny. Nazywam się wtedy odpowiednio do serwerów produkcyjnych. I zaczynam proces przywracania. Eureka! Mam teraz prawdziwe dane robocze na serwerach przywracania.

Chciałbym powiedzieć, że to był koniec drogi ... ale nie zadałem jeszcze pytania i że chodzi o to, że tak .... to jest?

PYTANIE: jeśli chcę przywrócić kopię zapasową pobraną z klastra replikowanych węzłów mnesia, jak zmodyfikować plik (podobnie jak w procedurze change_node), aby pozostałe węzły były ignorowane lub usuwane z kopii zapasowej?

Zapytany nieco inaczej: Jak przywrócić replikowaną bazę danych mnesia z wieloma węzłami () na pojedynczym węźle ()?