能看到这篇文章说明数据没有大问题。
不作死就不会死，因为最近论文需要用Cern开发的root来做数据分析，而root运行的最佳环境是ubuntu。我家里这台机器正好是个ubuntuserver，想着安装个图形界面然后远程连接，这样出门在外随时都可以跑分析了。
图形界面装好了root运行顺利，吃个饭庆祝一下，只剩泡面和6个过期的鸡蛋，将就吃吧。
不忍心将6个过期蛋直接扔掉，用平底锅怒煎3个蛋，盖在泡面上，偶对了，还有过期奶酪片，一起煎了。
吃了两口，上Youtube看了会儿视频，然后打开了论坛。
擦，Database报错，当时没觉得有什么大问题。Flarum对权限要求比较高，可能是刚才设置用户组之类的把权限动了，于是查了一下文件权限，没毛病。
正打算上sql后台检查一下的时候，我发现sql进程掉了。这情况以前倒是没发生过，我想都没想直接重新start了一下sql，报错，看日志一片erro也没看出什么名堂。花了5分钟上网查了一下，没找到直接的解决办法。接下来就是作死的开始。
在日本的VPS数据库每三天备份，而在家里的这个没开备份，sql掉了也直接导致我没法上后台备份。
我习惯性把data文件夹和sql文件夹拷贝了一份出来，直接重装sql。
装好了一切正常，想着是只要把data放回去一切就恢复如初了。结果不然，能看到表名和结构，但点进去报table doesn't exist。
这时候已经是凌晨2点了，我睡意全无。肚子甚至开始有些疼痛，看着碗里还有一半的泡面和残碎的鸡蛋，有些犯恶心。
已经是没有退路了，开始后悔当初删库重装的操作。
data文件夹里有每个表的frm和idb文件，frm文件非常小，里面存放了表的结构相当于列，idb会大一些，里面是数据，相当于行。网上有大量资料是关于如何从frm和idb中恢复数据的，基本逻辑是创建同名表和相同数量的字段，替换原来的frm修复结构，通过alter tabel 表名 discard tabelspace 删除现在临时的idb文件，再把原来的idb放回来，import tabelspace 建立连接完成修复。
如果手头有data文件夹下的ibdata1之类的这些文件，修复会更方便一些。
但我怎么弄也还都是报错。这时候再也无法直视那碗泡面了，我赶紧将它倒掉。刚回到房间，闻到泡面的残留味道，我立马回到水池，直接开始呕吐。大概是太久没吐了，一时忘了怎么吐，一上到喉咙就被卡住再也上不去。我此时弯腰，用手指伸入喉咙。泡面瞬间被以大于300g/s的速度被喷出，过多画面细节就不描述了。
我找到了最后一次的备份文件，2021年4月。半年前的备份啊，这是要损失多少内容。不过，在先导入之前的备份后，重新链接idb文件可以恢复表。但是当时备份的时候论坛的插件还很少，插件会增加表的内容，如果备份的表结构和后来的表结构不同，会无法链接idb。基本问题还是在表的结构上，我已做了最后的妥协，手动创建这些表。让我很失望的是，根据网上的资料，替换frm文件后，表的结构并没有更新，而如果要手动创建同名的所有字段，字段长度却又不知道。
接着又吐了好几次，天亮了。上午要帮同学交易一个镜头，勉强还撑得住，交易很顺利。
回到家立马就不行了，直接躺倒，开始发烧。每次醒来第一件事就是看时间，明明只过了两小时却感觉已经过去一整天。
发烧我不太吃西药，靠身体自己解决还能增加免疫力。喝了点清开灵，继续睡。次日凌晨开始腹泻，持续到中午，基本已经被掏空了。
头没那么疼了，抱起电脑继续处理数据库的问题。
我想到的另一个办法是，重新安装每一个插件，让其修改数据表，这样虽然数据是空的，但结构能够恢复。但这又引来了一个很蛋疼的问题，flarum是通过compressor安装插件的，插件目录也在flarum目录下。我直接安装插件是会被提示已经安装过的，卸载掉重装会导致目录里的文件被改变。为了个性化的改变论坛的一些样式，插件源文件我是修改过的，这么一来我的修改就全没了。这基本上等于我把整个flarum重装了，不到万不得已，不能这么做。
用之前的备份可以进到flarum后台，竟然还能看到那些新插件，直视点进去是空白。
我重新开始最初的操作，我注意到service mysqld stop 和 start 执行速度非常快，基本没有延迟。这次发现了关键的问题。在替换文件前，sql并没有停止工作。包括使用kill，都无法结束sql进程，因为还有sqlsafe这个进程存在，单独结束sql，sqlsafe很快会重启他。我直接连续两次kill，关掉了进程。
重新开启后，淦，表全恢复了。不需要重新链接idb什么的，完全恢复了。
刷新了一下论坛，调整了几个插件的设置，一切正常。
这次为了庆祝一下果断点了外卖，贵一点但是比过期鸡蛋安全。恢复后的第一件事就是开启了数据库备份。