服务器更新应用导致的异常及ln命令的使用

环境：CentOS 5.11

出现问题：

线上服务器运行mysql和gitlab，今天下午gitlab突然发生崩溃，尝试重启gitlab，重启失败。从gitlab日志目录下的unicorn.stderr.log看到报错

Refreshing Gem list
/home/git/gitlab/vendor/bundle/ruby/2.1.0/gems/activesupport-4.1.1/lib/active_support/dependencies.rb:247:in `require': /usr/lib64/libstdc++.so.6: undefined symbol: _ZNSt8messagesIcE2idE, version GLIBCXX_3.4 - /home/git/gitlab/vendor/bundle/ruby/2.1.0/extensions/x86_64-linux/2.1.0-static/charlock_holmes-0.6.9.4/charlock_holmes/charlock_holmes.so (LoadError)

此时有同事反馈mysql连接数过多，导致无法访问，尝试重启mysql，也是失败，表现跟我之前一篇mysql报错Cannot check for MySQL Daemon startup because of mysqladmin failure里写的完全相同。

问题分析：

在发现mysql重启失败前，对gitlab报错做了一些分析，开始是围绕charlock_holmes.so(LoadError)，发现网上的资料，似乎跟我的问题都不相同。(其实应该围绕libstdc++库报错来解决，这个才是主要原因)

解决mysql的报错，还是采用之前文章里的老办法，将mysql卸载重装。重装完成后，启动mysqld，发现同样报了一个libstdc++.so.6的错误，之前一直运行正常，推测是这个库被动过了。ls -l /usr/lib64/libstdc++.so.6，发现最近修改时间是上个月，验证了自己的猜测。软链接指向的是libstdc++.so.6.0.17，同时目录下还有一个libstdc++.so.6.0.8。根据libstdc++.so.6的报错来查找资料，提到一个解决方法是降低版本(downgrade，参考链接)，尝试把软链接指向改位低版本的libstdc++.so.6.0.8。

ln -s /usr/lib64/libstdc++.so.6.0.8 /usr/lib64/libstdc++.so.6

ln命令建立软链接用法: ln -s 源文件 目标文件 

很方便的一个命令，一个场景是用于这种lib库的指向，另外一个可以解决移动文件路径后导致的找不到原路径下文件的问题，只要在原路径下建立一个软链接即可。

修改完libstdc++.so.6的链接指向后，再启动mysql，发现可以成功启动，其实gitlab也是同样的原因导致的，因此gitlab也能成功启动。

总结：

猜测是由于其他的程序安装或者更新操作导致了libstdc++.so.6这个链接发生了变化，以后遇到类似的报错

/usr/lib64/libstdc++.so.6: undefined symbol:

可以首先从libstdc++.so.6的版本来进行尝试解决。