在这期间，我的提供者不得不强制重启服务器（拔掉插头），启动后，MySQL服务器出现问题（我正在使用MariaDB）。
经过几个小时的研究，我找不到问题的主要来源或任何解决方法。 该网站相当庞大，涉及比特币，可能会损失数千美元的账户余额（不是真的失去了，只是没有与他们各自的所有者的联系），我很恐慌。
不知何故，文件夹/ var / lib / mysql'转换'成一个同名的文件mysql，它包含乱码： http : //pastebin.com/XbY5YLpG
我也查看了MariaDB的日志文件，在这些文件中有几GB的查询。
有没有任何可能的方式，我可以检索数据库？ 我很沮丧
有一个程序mysqlcheck随mysql附带，允许你修复表，如果你可以启动mysql和你的表损坏。 听起来不像是这样的情况。 还有另一个程序myisamchk ，它允许你确保你的MyISAM表的完整性（你没有使用innodb，是吗？），只要你有与他们有关的文件; 它将使用他们的关键约束和期刊。
但是，由于您的文件系统似乎损坏并丢失了数据库文件，因此您不能使用这两者中的任何一个。
即使假设您的数据仍然存在（如果目录条目已经变成文件，那么您的文件的所有引用都可能被删除，并且磁盘空间被回收），如果在该文件中，您无法将其恢复到一个可用的格式。 如果碰巧你的文件系统可以被修复，而且数据实际上仍然是被引用的（对你的文件系统使用fsck），你可以得到这些文件并按照正确的顺序放回去，见第一段。
我想你可能刚刚学会了一个非常昂贵的教训，说实话。 保持备份！
在我写完之后，其他人发现你是谁 ，还有其他一些与此相关的东西 。 我想你们正在备份，而且真的，你们将需要从这些备份中恢复过来，因为它可能会让人感到不舒服。
如果你不能容忍甚至两天的备份，更频繁的备份是一个明显的解决scheme; 另一种解决scheme是保留可以故障切换到（并从中恢复）的活动副本集。 他们就像备份，但只能在这样的情况下工作（即不被恶意黑客破坏数据等）。
如果可能的话，您应该在提供者或电力服务器之间移动之前特别保留备份。 另外，你所引用的症状可能表明一个坏的磁盘，这将很快解释。
另外请注意，如果数据库运行缓慢，可能会非常高，因为它正在执行一些昂贵的操作，例如重试写入或编制索引或重新平衡等。 这是热重启将会破坏数据完整性的确切时间。
从商业angular度看，祝你好运。 我相信你的数据通过你的最后一个备份点已经完成。
这里另一个重要的教训是，如果您要为某个人收费，并且业务连续性非常重要，并且数据丢失是不可容忍的，则需要在系统中构build冗余。 运行mysql的单个节点，正如您已经很好地演示的那样，不够可靠或冗余。 这对于单个VPS是双重的。 正确的做法是使用VPS提供商，它允许您明确地将服务器放置在不同的地点和不同的networking上，或者最终购买自己的服务器并将其放置在不同的数据中心。