一次线上紧急异常排错的“辛路历程”（一个Sh脚本解决1T文件迁移）-一一网

1. 背景

下午6点，客户反馈BUG管理系统上传附件突然出现未知异常，阻塞了测试人员提单，于是跑到机房，18:10 通过df -h命令发现，BUG系统日志所存储的 /home还剩下14k（总空间1T），脑子里面飘过来领导的话，先解决用户的问题，再深入调查。

2. 过程

18:20，打算释放空间，先顶一会，同时在客户大群发出通知20:00 准时进行磁盘扩容，先通过 cd到/home目录，du -sh ./* 命令，线上服务的JAR包，前端工程的包都放在 /home目录下（强烈建议，在申请服务器的时候，让IT将20T空间的磁盘挂载到/data目录下，将文件存储和大文件相关的包全部放到该目录下，而且定期去备份）. 于是将用户后端部署的JAR包，授权，网关，配置中心等核心服务JAR包，及拷贝全部删除，再次执行 df -h ，/home目录多了1G的空间. 暂时轻松一会了.

19:00 通过监控发现，BUG附件上传接口调用频繁，每个文件都在50M-200M不等，看着架势，估计一顿饭的功夫不到，立马就满了，果然，在19:30的时候，/home空间又剩下了12k（崩溃的节奏），看来等不到20:00，于是加紧准备扩容迁移.

19:50 IT已经将20T的磁盘挂到/data目录下了，接下来需要将/home近IT的数据迁移到/data目录下，脑子里面已经有了过程中可能会出现的风险 1) 服务器在西安，笔者是通过机房中的一台WIN10下的PowerShell ssh user@ip 来登录的，风险一： SSH连接linux时，长时间不操作就断开，风险二: 文件名称有特殊字符而且长度超长，会存在无法cp异常的问题 风险三：按照1小时同步200G的速度，至少5个小时起步，如何做到无人值守，后台静默同步.

针对风险二【文件名称有特殊字符而且长度超长，会存在无法cp异常的问题】，笔者尝试使用 find . -name “*” -exec cp -r {} /data/ \ 命令来解决这个问题. 但是无法解决风险三，顺便说一下，我们在存储文件时，文件路径名称要唯一，比如说在前面增加一个UUID等，便于迁移过程中万一出现中断异常，可以覆盖更新，针对风险三，内部讨论之后，可以写一个sh脚本，通过nohup command & 在后台不挂断的运行命令.同时可以解决风险一【SSH连接linux时，长时间不操作就断开】

3. 干货来了

3.1 附sh脚本，可以直接使用.

前提将源目录下的文件清单地址输入到一个list文件中，ls /data > list，此时记录当前文件个数便于，迁移结束后对文件总个数进行核对，ls -lR | grep “^-“| wc -l

vim sync.sh ，通过i,进入到编辑模式

`#!/bin/bash

source=”/home/data”

dest=”/data”

echo “begin”

while read line

  echo "begin to copy $line" 

  cp -raf $source/"$line" $dest 
复制代码

done < list

echo “end,success”

按住ESC，:wq即可保存然后执行 nohup sh sysnc.sh & 等二天过来，通过ls -lR | grep “^-“| wc -l 来对比数量.

3.2 笔者采用docker方式来部署服务，修改容器映射目录

以docker-compose.yml为例，修改，volumes:
– /data:/root/itsys/files 对应的映射目录地址. 需要重新docker build -t 镜像名称 . 才行.

4. 总结&反思

我们在做部署架构设计的时候，就要考虑到业务量的增长对系统带来的影响，通过用户体量和业务数据的分析，预测出未来基础设施（CPU，内存，存储等）相应的调整方案. 对于重要的业务数据，要定期备份，比如缺陷管理的BUG的LOG日志，这样数据如果丢失，研发人员将很难进行BUG的修复.

技术债务是需要偿还的，如果在最初部署的时候，考虑到将文件目录挂载到足够空间的磁盘上面，就不会有后面线上异常需要紧急处理了.

另外即便是扩容过程中出现的问题进行了分析，还是会出现其他的异常，此时我们要调整好心态，只要方案是正确的，过程中出现的问题我们要克服，比如，cp命令增加了f,还是会出现目标目录有相同文件时，脚本抛出重复文件名称提示的问题【通过vi ~/.bashrc, 在alias cp=’cp -i’前加上”#”注释掉这行以解决】.