晚上我的提供商不得不强制重启服务器（拔掉插头），启动后，MySQL 服务器出现问题（我正在使用 MariaDB）。
经过几个小时的研究，我找不到问题的主要根源或任何解决方法。该网站相当大，涉及比特币，可能有数千美元的账户余额丢失（不是真的丢失，只是与各自的“所有者”没有关联），我很恐慌。
不知何故，文件夹 /var/lib/mysql “转变”为一个同名文件 mysql，其中包含乱码：http://pastebin.com/XbY5YLpG
我还查看了 MariaDB 的日志文件，这些文件中有几 GB 的查询。
有什么办法可以恢复数据库吗？我非常沮丧。
答案1
有一个程序mysql检查它随 mysql 一起提供，允许您修复表，如果您可以启动 mysql 并且您的表已损坏。听起来不像是这种情况。还有另一个程序myisamchk，只要您拥有与 MyISAM 表相关的文件，它就可以使您确保 MyISAM 表的完整性（您没有为此使用 innodb，是吗？）；它将使用它们的关键约束和日志。
但是，由于您的文件系统似乎损坏了并且丢失了数据库文件，因此您无法使用其中任何一个。
即使假设您的数据仍然存在（如果目录条目已转换为文件，则可能所有对您的文件的引用都消失了，磁盘空间已被回收），如果它在该文件中，您就无法将其恢复为可用的格式。如果您的文件系统偶然可以修复并且数据实际上仍被引用（根据您的文件系统使用 fsck），并且您可以获取文件并将它们恢复到正确的顺序，请参阅第一段。
说实话，我想你可能刚刚学到了一个非常昂贵的教训。保留备份！
在我写完这篇文章后，发现了你是谁和与此相关的其他内容。我猜你保留了备份，而实际上，你需要从这些备份中恢复，并承受可能令人不快的损失。
如果您无法容忍两天前的备份，那么更频繁的备份是一种显而易见的解决方案；另一种解决方案是保留可以进行故障转移（并从中恢复）的实时副本集。它们就像备份一样，但只适用于这种情况（即，不适用于恶意黑客等破坏数据的情况）。
你应该尤其如果可能，请在供应商之间移动或关闭服务器之前保留备份。此外，您引用的症状可能表示磁盘有问题，这很快就会解释很多问题。
还要注意，如果数据库运行缓慢，很有可能它正在执行一些昂贵的操作，如重试写入、索引内容或重新平衡等。这正是热重启会破坏数据完整性的确切时间。
从业务角度来看，祝您好运。我相信您上次备份点之后的数据已经完蛋了。
这里的另一个重要教训是，如果您正在向人们收取费用，并且业务连续性很重要，数据丢失是无法容忍的，那么您需要在系统中建立冗余。正如您所充分证明的那样，运行 mysql 的单个节点不够可靠或冗余。对于单个 VPS 来说更是如此。正确的做法是使用允许您将服务器明确放置在不同位置和不同网络上的 VPS 提供商，或者最终购买您自己的服务器并将它们放置在不同的数据中心。