记一次AIX服务器文件迁移事故

生产Aix服务器文件已经迁移了几次，一直没有成功，运维的领导已经不满。后台日志发现报错out of memory，查看相关的内存指令发现，oracle进程占内存较大，后来发现其实并不是。今晚联系到数据库的运维人员把oracle服务给停掉了。

---

1.kill带来的隐患

shutdown掉oracle的进程之后，发现对内存的改观并不是很大。有一个usr文件夹里面有，一个大的文件nmbd.log，百度是samba服务在运行过程中打的日志，上次已经删除掉，但是估计由于aix系统原因，不重启不释放相关内存的原因，一直导致该文件夹100%占满。就想着那要不要把samba服务停掉，然后我们就可以正常的把usr内存给释放出来。然后鬼使神差地使用了ps-ef|grep nmbd。发现有两个nmbd的 process进程。先kill掉了第1个没有反应，接着把第2个也杀了。哦吼，完蛋，发现突然连接中断，公司的堡垒机ssh连不上服务器了，ping也无法通。然后就想着要联系机房的人员进行服务器的重启。

---

2.一波三折，机房人员竟然只是手动点了开关机键

不知是我们描述的不够清楚，还是机房本来的操作水平就不够高，结果他们就是手动点了关机键。机房人员反馈他们摁了很长时间，机器还是没有反应。在此期间我们也尝试一直去连接服务器，过了一会儿服务器能连接上了。竟然好了，有点开心。然后发现后台进程什么都没有，需要把weblogic和oracle服务全部启动起来，然后挂载上一个硬盘。重点来了，我们挂硬盘的时候，发现mount不上去。报错是需要我们自己去手工fsck去清理一下磁盘,才意识到机房人员暴力关机导致磁盘相关损坏。

---

3.ds5020 磁盘备份失败，采购之殇

此时已经联系到aix相关硬件人员，发现磁盘硬件目前正常，目前如果需要我们清理磁盘的话，有数据丢失的风险。运维工程师为了以防万一，决定将磁盘进行备份操作。了解到有相关快照功能，观察了磁盘空间充足，按照图形化界面一步步点过去，结果到了最后一步需要输入密码。试了几次之后都失败，然后磁盘被锁定十分钟。此时已经是晚上11点多，然后又联系到了一个厂商人员，如果需要重置密码的话，按照他的步骤，通过串口线需要IBM的Key。这个机型已经很老了，一直没有进行相关的维护操作。所以。Key后来公司就没有去进行后续购买。这条路也走到了尽头。

---

4.背水一战，磁盘是否能够起死回生

此时现在问题又回到了原来的起点，磁盘是否能够执行修复操作，又联系到了，刚刚看axi的运维大神，据他反馈他直接修复过的aix系统，只有一台修复失败了，是把文件全部丢到了回收区，文件无法使用了，其他都修复成功了。经过反复确认，最终确认磁盘文件清理过程中全部丢失的概率几乎为0，只是其中有可能部分坏道导致文件损失，主管此时分析如果有少量的文件丢失还是可以容忍的，因为我们的影像文件在客户经理的手上都有，此时主管已经跟相关领导进行相关报备中工作，着手进行磁盘修复。

此时每个人都冒着巨大的压力，想着如果一旦文件丢失，后续该怎么办，想到了最坏的结果丢失之后，可以把信贷现在生产服务器切换到最新的影像系统，但是以前的影像文件都没有了，这也是下下之策。

焦灼的等待之后， Aix工程师终于传来好消息，磁盘已经把修复完成，也帮我们挂上去了。上去检查了一下，果然已经有了。此时欢呼的声音在脑中回荡。

---

5.临门一脚，启动服务

折腾一圈，终于把服务器搞好了，现在就是要把各种服务给启动起来，先启动了oracle进程没问题，打开了oracle的监听端口。下一步是启动weblogic进程。问题又来了，启动过程中报错，报错日志说数据库用户被锁。此时登陆了应用信贷系统去连接目前迁移的影像系统，发现连接失败，证明服务并没有去成功。该问题需要被排查。

厂商这边使用了命令之后发现是CM2账号被锁，紧急联系数据库管理员，数据库管理员问我们是不是起错了weblogic的进程，主管反馈没有。数据库管理员让我们自己手动解锁一下用户。解锁完发现该用户已到期，陷入了尴尬的境地。如果一旦改数据库用户的密码，我们工程的配置文件也将同步进行修改。此时也是我们最怕的地方，因为你不知道有几个地方需要修改。还好我经过搜索之后，发现可以用现有的密码去更新密码就可以保持密码不变。试了一下，数据库用户过期状态变成open，一切正常。重新启动服务还是报数据库用户锁定。挠了头皮之后，主管点了一下服务连接正常，OK，终于大功告成，不再折腾。此时已经是凌晨1:30。

---

6.前进，继续进发

看了一下服务器的内存，现在有很大的free空间，应该是之前重启释放了很大一部分，然后我们决定继续执行之前的迁移指令，把64位的java jdk放上去了，然后把Java的运行参数设置为4g，监测了一会迁移命令后台一切正常，终于今天可以尘埃落地。

打算下午再去看一下，如果一切正常的话，可以继续执行后续的操作建议工作，今天算是终于有了一个突破性的进展。

总结本次迁移的教训：

• 不要擅自做超出自己范围的事情，jdk本来不应该我们来安装，相关部门去安装就可以
• kill命令要使用谨慎
• 公司层面加强对服务器的巡检，不要舍不得钱去做一些硬件后续购买维护