最近公司服务器上的mysql突然崩盘,引发了一系列的血案。连续三天一直在想办法,考虑怎样恢复数据,始终是徒劳。中间老板请了专门做数据恢复的大神,最后在周五下午终于恢复了所有数据。果然,大神都不是这么简单的。能从MySQL的bin-log日志及ib-log数据日志中全盘恢复数据,这是我不能够想象的。

我自以为很简单的,也是最直接的方法,直接文件恢复,在听了大神的说法后,被无情抛弃了。我们在mysql崩盘之后,一直围绕着远程连接mysql的报错,及启动mysql服务的报错,和数据日志报的错打转,但就是没有实质性的进展。这时候一位同事,脑子不知道怎么想的,直接按照他在网上教程上的说法,初始化了mysql数据库./scripts/mysql_install_db --default-file=/etc/my.conf。这时候的我看到存放mysql数据的目录下满满的都是bin-log文件,我以为数据都还在,但考虑到数据不能被污染,也是听了那同事的建议(他在拷贝数据文件下的文件到本地,慢得要死),就直接cp data/* databackup/,没有考虑到,文件恢复,是要保留现场的,最好是关闭服务器上所有进程,取消磁盘的挂载(当然这不现实)。这样的大规模的磁盘操作之后,想要恢复,基本已是奢望(我自己不服气,还真的用retundelete恢复了一下,确实渣都不剩一点了)。

公司的数据库数据丢失还不是最恼人的,在mysql挂掉当天之前,到今天才找到原因的远程连接挂掉才是。在那天挂掉之前,我想用putty连接一下我自己的服务器(就是现在这台)。可是突然告诉我,The Authenticity of host xxx can't be established,什么什么的不能创建,然后往本地known_hosts添加这一主机。这个很像在我使用putty第一次连接某个服务器的时候回弹出来的内容,但想想又有点不一样。我没怎么考虑,就直接点了yes。然后输入账号,回车,直接弹框报错,permission denied (publickey)。之后这个就像魔障一样一直不停的出现在我的眼前。我用git bush 中的ssh直接登录,也是这个错。中间试了一下其他的服务器,有的直接登录了,有的也登不了。然后中间还提醒说,有可能是中间人攻击,也有可能是host key发生了变化(本地还是服务器,忘了)。感觉一团糟,什么头绪都没有,然后还要不停地盯着公司的服务器想办法恢复。太累了。之后有找阿里云去申请工单。他说远程连接没问题,分析得也对,因为我家里的电脑是可以登录的。然后就是查看服务器上的ssh配置文件,防火墙,阿里云控制台的安全组,都没改过,确认了一下,忍不住按照各种教程,来回改,但是核心的 PasswordAuthentication yes是没有问题的,防火墙我压根没开,然后安全组也是最简化版本的。这时候就让我抓包试试,我也抓包了,可是他分析了一下,得出的结论是,没有问题,三次握手成功,没有reset。然后最终版的建议就是,换一个ssh工具。没办法,如果真的是工具问题,那就换吧!下了个破解版的XShell和secureCRT,竟然没有让我输入密码,如XSell直接就只有一个设置公钥文件的选项。这就把我带沟里了。我想的是,那肯定是服务器没有开启密码登录授权的方式啊,但是我并没有改过这些配置,尤其是其他的服务器也是这种情况。这就是一个死胡同。
然后,今天加班,早早地过来找原因,各种错误,各种搜,方法也是试了好多种了。找到一篇关于远程连接错误排查的文章,是阿里云上的。https://help.aliyun.com/knowledge_detail/41470.html?spm=a2c4g.11186623.4.1.40b66cd3DyxjAw

说先排查服务器,配置,ssh服务是否开启,还有就是服务器本地连接 ssh localhost/127.0.0.1 是否成功。这些服务器端的都检查了一遍,没有问题。然后是客户端,不同的ssh客户端依然无法登录,我甚至用了同事的电脑下了一个putty,然后连接,依然是这样的错误。所以客户端应该是没有问题的。然后就是中间网络了。telnent服务器的端口,也没问题可以通。之后文章下面连接的一些错误排查,有相同的,如:SSH 登录时出现如下错误:Disconnected:No supported authentication methods available,可是,它还是让我去修改ssh配置文件,这就让心情一下子糟糕起来了。这样是不行的呀。

刚好排查到网络层级,我想到网络层,换一个网是不是就好了,我家里的能连接,这不就是佐证吗?赶紧开个热点,连上wlan,然后打开putty,连接服务器,然后就像第一次连接一样,弹出存储公钥之类的提示信息。确认后,输入root,回车,呼~,从前的我又回来了。

问题找到了,公司在路由器接入的地方加装了一台服务器,也做了一些配置。这可能就是导致提醒中间人攻击的原因。真可怕。终于找到了原因,不然我感觉自己都要快崩溃了。轻松连上服务器,上传文件,svn备份。ok,下班!

注:中间有过重启服务器实例之类的,导致svn服务挂了,然后早上在家准备备份数据的,发现cornerstone停止工作了,报错了。mmp,排查过程中,把它启动了,然后svn没问题了。