由于过高估计了实施的脆弱性，我已经损坏了我的Mnesia数据库而无法修复。当我尝试使用Mnesia API时，即使它们的键在文件中可见，我所需的记录也不可见。即使文档指出Mnesia工件是DETS文件，它们也无法打开或识别为DETS工件。 PS：dump_to_textfile（）也不起作用。
答案 0 :(得分：0)
最终我能够转储我的数据库。它没有结束我的Mnesia问题，但它给了我以前没有的选择。
SETUP： 最初我实现了一个master-master mnesia集群。 （阅读文档）。事实证明，即使是经验最丰富的Erlang程序员也不会使用Mnesia复制，因为存在许多缺陷。事实上，我从Erlang内圈和一些L1团队那里得到了这些信息。然而，就我而言，这项工作已经投入生产。当问题出现时就是这样。
我们开始收到数据库一致性错误，以及我最喜欢的网络或数据库分区错误。它需要一个非常高技能和知识渊博的个人来提前恢复以及许多规划和代码;我没有。
最终我采取了两个步骤。 （a）删除了第二个应用程序，以便即使数据库位于主 - 主集群中;一个人是奴隶，因为它从未被用作主人。 （b）在第二个实现中，我拆分了集群，以便应用程序在具有单个DB的单个节点上运行。 #a正在生产中，＃b是热备用。由于写入非常罕见，因此复制是手动的。
在单节点部署中，有两个节点。第一个节点是应用程序; app @ ks和相同的硬件是一个＆＃34; erl＆＃34;节点，当我需要rpc进入应用程序，看看情况如何。
我的解决方案： 当我发布这个问题时，我试图转储我的Mnesia DB的内容。我遇到了很多问题，因为我正在尝试从管理节点访问数据库，因为应用程序节点正在运行。
因为我试图从erl节点访问mnesia lib，所以DB不是本地的erl节点，所以dump_to_textfile产生了一个空文件。当我使用rpc告诉app @ ks节点转储时，我最终取得了成功。
仍然未定义 当我启动管理节点时，我将mnesia dir参数设置为与app @ ks节点相同的文件夹。我有一个模糊的记忆，这是不可取的。
还有更多的Mnesia问题要解决，但没有一个涉及我报告的问题。但我仍然不知道如何从各种数据库文件中提取原始数据。