Dreamer2q Blog
见到,不如不见
Dreamer2q

Code is cheap, talk is expensive

64日志

记一次修复mongodb的经历

创建于 2021-03-24 共 1186 字,阅读约 5 分钟 更新于 21-03-24 18:13
浏览 56评论 0

学校服务器老是挂掉,上一次服务器的文件系统就莫名的出问题了,导致所以依赖它的数据库都挂掉了。我一开始还以为只是某一个数据库挂断了,然后折腾了半天也没解决,都准备放弃数据时才发现其它数据库也挂了,才意识到是文件系统的锅啊。这波,最后以重启服务器解决告终。


然而好景不长,最近服务器老是出问题,一些小问题就没怎么在意,只不过这次直接是关键节点关键服务出问题。没错,我说的就是docker出事情,有一个task挂起,超时。然后整个系统涉及的进程的,例如ps,都卡住不能用了。我想结束docker服务都无能为力。最后我祭出了我的杀手锏, reboot 这个命令把自己给踢出去了,然而系统还处于一个未能重启的状态,我可以ping通,但是连不上。无奈只能找老师帮忙强制重启qwq。


于是,我学会了如何强制重启Linux

Linux使用shutdown -r now 或者 reboot、init 6 命令无法重启时使用以下两条命令可强制重启:
echo 1 > /proc/sys/kernel/sysrq  
echo b > /proc/sysrq-trigger  
1./proc/sys/kernel/sysrq
向 sysrq 文件中写入1是为了开启 SysRq 功能。根据 linux/Documentations/sysrq.txt 中所说:SysRq 代表的是 Magic System Request Key。开启了这个功能以后,只要内核没有挂掉,它就会响应你要求的任何操作。但是这需要内核支持(CONFIG_MAGIC_SYSRQ 选项)。向 /proc/sys/kernel/sysrq 中写入0是关闭 SysRq 功能,写入1是开启,其他选项请参考 sysrq.txt。

2./proc/sysrq-trigger
立即重新启动计算机:
echo "b" > /proc/sysrq-trigger
立即关闭计算机:
echo "o" > /proc/sysrq-trigger
导出内存信息:
echo "m" > /proc/sysrq-trigger
导出所有标志位和寄存器信息:
echo "p" > /proc/sysrq-trigger
导出线程状态信息:
echo "t" > /proc/sysrq-trigger
使系统崩溃:
echo "c" > /proc/sysrq-trigger
同步连接系统磁盘:
echo "s" > /proc/sysrq-trigger
重新挂载所有文件系统为只读:
echo "u" > /proc/sysrq-trigger
此外还有两个,类似于强制注销的功能:

'e' — 使用 SIGTERM 信号杀死除 init 进程外所有进程
'i' — 使用 SIGKILL 信号杀死除 init 进程外所有进程


强制重启的代价

重启后,我发现问题依旧,我在极端愤怒的情况下吧Docker直接卸了,然后又删除了许多真他妈的无用的大小,包括livepatch, promethus, blackbox。这些玩意我都没见过,查了一下,大部分都没有用处的,由其是那个xxx_export,就是问题的根源。把这些都干掉,发现服务器反应速度快了不少,舒服了。


做完这些之后,我才意识到强制重启的代价。那就是,mongodb数据库未正常退出,导致的数据冲突。没办法,还好mongodb还有挽救的希望。


IMG_20210325_002342.jpg

我以为简单修复一下就行了,但是修复一半发现mongd有个 ​segmentation fault​ 的错误,好家伙直接访问0地址了。然后,我看了下当前版本,4.0.x,于是升级到了4.2的版本,重新跑了一下,这次总算是过了。


好吧,到这里就是无聊的善后工作了。这次修复还是很有收获的,但是代价就是大半夜的还在补作业,补完作业又马上来写文档,这比996还九九六呢。


总结与反思

这次事件暴露了很多问题,第一个问题就是对服务器上的配置了解的还是不够,还有许多知识上的缺漏;其次就是,应急方案无。理想情况是,应该有一台从服务器,主的挂了可以无缝切换。但是,目前服务都是跑在docker上的,包括数据库,文件数据通过NFS来实现共享的,这就导致那台文件服务器的压力很重,加上那台服务器配置本来就不高,挂掉也只是时间的问题。解决措施,提供一份应急方案,不能完全依赖服务器可靠性,例如通过挂载oss盘的方式来提供应急的fallback。