1: 这次操作的原因是

    由于mysql数据放在/分区，而/分区快被写满了，只能把mysql数据移动到别的分区。

2: 所做的操作

    由于怕移动的时候由于意外被中断掉，使用nohup mv mydata/  /data &去移动。

3: 发现危险

    由于总共的数据39G，但发现移动到4G的时候，好像mv命令停止了，当初以为是在移动ibdata1这个文件比较大，所以这样。当初感觉有点奇怪，就看了下mv进程，发现处于T的状态，网上顺手查了下，查到这篇文章，

4: 吃饭时的讨论

    吃饭时跟同事在说，这次移动mysql数据的时候有点奇怪，好像移动数据的时候停止不动了。进程处于T的状态，然后我又用nohup执行，不知道发生了什么情况。同事顺口回了，用strace -p看一下就知道了，会逛刷。当时还没意识到mv被strace -p了，然后处于停止的状态。

5: 吃饭回来的时候

    发现应该已经移动完了，但数据还是一样，没有动过。同事说到strace，而我在文章中刚好也看到了，就再认真再看了下，发现如下说明：当进程正在被跟踪时，它处于TASK_TRACED这个特殊的状态。“正在被跟踪”指的是进程暂停下来，‍‍等待跟踪它的进程对它进行操作‍‍。比如在gdb中对被跟踪的进程下一个断点，进程在断点处停下来的时候就处于TASK_TRACED状态。而在其他时候，被跟踪的进程还是处于前面提到的那些状态。

6: 问题解决

    想到可能被strace了，‍‍刚好同事说我在mv的时候，他顺手strace了一下‍‍，后来同事ps看了一下，发现strace进程没退出，用kill -9强杀后掉strace后，可以正常移动数据了。做了软链接，恢复了mysql服务，

7: 事后总结

    使用mv来移动重要数据风险还是比较高的，特别经历这次以后，发现mv是个比较危险的命令。也发现了一个重大情况，strace竟然会导致mv中止。幸好没出什么大事，不然数据量大，再弄个从库时间就太长了。

8: 改进方案

    使用cp拷贝数据过去(cp mydata/ /data/)，使用mv换个名字(mv mydata mydata1)，做个软链接(ln -s /data/mydata mydata)。最后rm -rf mydata1/即可，比较安全的方案。