小编在运维的工作中，经常能碰到各种各样的坑，下面是小编曾经遇到过的一个问题，希望能给各位一点参考。
某一天，一个同事向我求助，说某个项目的数据库无法通过集群的方式进行连接（数据库是公司自己研发的，类似Mysql）。
当日解决步骤：
1. 首先批量查看了集群的磁盘空间使用情况，发现磁盘空间正常，再检查电脑集群的数据节点服务及其他服务，均正常运行。
2. 再次检查管理服务器配置文件，发现服务器集群一共是node1-node28，而scmt批量查看的末节点只到了node24，即重新修改批量命令，发现node28的数据节点无法启动。
3. 查看node28的磁盘空间发现，/dev/sdb满，使用du -sh *的方式排查发现了脏数据表，将其删除之后，想通过lsof的方式释放进程，结果发现服务器没有lsof的命令。
重点来了！！本来正常的处理方式应该是下一个rpm包安装lsof命令，或者是通过暂时关闭数据节点的方式释放deleted进程，但偏偏选择了从其他集群拷贝lsof安装包的方式。
拷贝步骤（错误示范）：
1. 进入顺德公安其他服务器下面也没发现lsof的包，想着说只能通过从其他地方的服务器将/usr/bin/lsof以及安装文件（rpm -q /usr/bin/lsof）拷贝过来。
2. 当scp完成之后，修改权限，执行lsof命令发现报错，缺少libc.so.6下面的某个动态库的文件，这时候为了赶时间（下午要演示），没想这么多，就把centos6.7的libc.so.6文件拷到了centos6.2的/lib64/下，整台服务器直接断开远程连接。
到这里，各位应该知道原因了吧，系统版本不同，库文件内容也不相同。
挽救思路：
通过文献查到了libc.so.6文件的真正含义，是整个服务器的动态库环境，几乎所有的命令都是通过搭载libc.so.6来完成的，而幸运的是，libc.so.6是一个软连接文件，也就是说，能通过相同版本的centos进入救援模式，将软连接的源文件（libc-2.1.2.so）重新移植电脑到lib64目录下。
最后解决流程：
1. 查看node1系统版本为centos6.7，天真地认为node1-node28都是centos6.7，结果后来才发现为centos6.2.。。。
2. 将centos6.2的iso文件下载，并通过ultraiso软件写入U盘作为启动盘。
3. 修改服务器bios启动，将U盘作为第一启动项启动，进入RESCUE模式，在这里需要注意的是，centos6.2会让你选择initrd.img的位置，需要在hardisk里面选择/dev/sdx（U盘），然后等待片刻即可。
4. 进入rescue模式之后，找到原系统的位置/mnt/sysimages/，输入
cp /lib64/libc-2.1.2.so /mnt/sysimages/lib64/libc-2.1.2.socp /lib64/libc.so.6 /mnt/sysimages/lib64/libc.so.6
可能会遇到/mnt/sysimages read-only的报错，这时候输入
mount -o remount rw /mnt/sysimageschroot /mnt/sysimages/
即进入原系统测试，测试方式可以是ls,cp等命令。当时花了一个下午把系统恢复，所幸没造成什么影响，在这里要提醒各位，在生产环境进行所有操作的时候一定要谨慎谨慎再谨慎，能不用root就不用root，以免造成重大失误。
电脑