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