警告:背景信息很长.如果您认为在背景信息之前需要问题,请跳到底部.欣赏这将要采取的时间!
我一直在网上(阅读谷歌),我没有找到一个好的答案.是的,在erlang.org网站上有很多关于Mnesia文档的链接和参考,但即使这些链接也受到版本的影响.
因此,在最简单的情况下,您当前连接的节点()与表集的所有者相同,那么备份/恢复将起作用.例如:
$ 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}]).
嘿,这很棒!
但是,如果数据库实际上是在远程接口上的远程节点()或远程节点()上运行,那么您必须以这种方式启动备份:
$ 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}]]).
当然这也很简单.现在这里是棘手的事情....
但事情变得复杂了.虽然我的熟人是erlang和mnesia专家,他们认为mnesia的复制存在严重缺陷,你不应该使用它(目前我还没有其他替代方案,你有什么机会实现更好的版本;不是可能)
所以你有两个节点()复制ram和基于光盘的表.您一直在使用默认的BackupMod维护使用标准备份定期备份数据库的策略.有一天,经理会要求您验证备份.只有当您尝试还原数据库时,才会获得:
{atomic,[]}
根据文档,这意味着没有错误......但是没有表格被恢复.
不想跑你记住,节点()和主机名必须匹配,以便您更改主机名和-sname参数去那里数据被备份的计算机匹配change_node程序.但是这次你得到一个奇怪的错误:
{aborted,{'EXIT',{aborted,{bad_commit,{missing_lock,mydatabase@otherhost}}}}}
仍然不想运行change_node过程我快速克隆恢复我的服务器,以便我有两个类似的机器.然后我恰当地命名以匹配生产服务器.然后我开始恢复过程.找到了!我现在在还原服务器上有真正的工作数据.
我想说这是路的尽头......但我还没有问过一个问题,而且问题的重点......所以这就是它？
问题:如果我想恢复从复制的mnesia节点集群中获取的备份,如何修改文件(类似于change_node过程),以便忽略其他节点或从备份中删除？
问题略有不同:如何在单个节点()上恢复复制多节点()mnesia数据库？