问题
mysql 导入任务时，由于导出的 sql 文件是在很大 （30G），利用 SQLDumpSpliter 切割工具 切成几个 1G 大小的 sql 文件
结果在导入大半天，突然报错 （另一个服务器上更惨，都导入两天快完成的时候，也报错了，那个是 ubuntu 20.04 ，后续再写）
20191230_154230_03.sql: write error (disk full?). Continue? (y/n/^C)
处理过程
-
查看磁盘占用情况
df -a文件系统 1K-块 已用 可用 已用% 挂载点...tmpfs 8128668 0 8128668 0% /dev/shmdevpts 0 0 0 - /dev/ptstmpfs 8128668 8640 8120028 1% /runtmpfs 8128668 0 8128668 0% /sys/fs/cgroup.../dev/mapper/centos-root 52403200 52064648 338552 100% /.../dev/mapper/centos-home 147899844 32992 147866852 1% /home/dev/sda1 1038336 196772 841564 19% /boot...# df -h文件系统 容量 已用 可用 已用% 挂载点.../dev/mapper/centos-root 50G 50G 335M 100% //dev/mapper/centos-home 142G 33M 142G 1% /home... -
想当然认为 tmp 临时文件太多了，删除 tmp
# ls /tmp -l总用量 0drwx------. 3 root root 17 8月 10 21:40 systemd-private-1408eb49d4e14c48b6e70c22ff965768-chronyd.service-H72jr9drwx------. 3 root root 17 8月 10 21:44 systemd-private-4c01797c31bf4a4dbb9ef7bd2735e39b-chronyd.service-S6gwnJdrwx------. 3 root root 17 8月 10 22:08 systemd-private-74265bf9678649f7be1d9095a0303a41-chronyd.service-yY6sZCdrwx------. 3 root root 17 8月 11 01:15 systemd-private-ea7fdb52f3094cf088283fc820f29e06-chronyd.service-wtvh3qdrwx------. 3 root root 17 8月 10 21:51 systemd-private-fc233b8722b74a3c9a79417eb7e8b857-chronyd.service-MPdEIR# rm -rf /tmp/*# ls /tmp -l总用量 0 -
删完再仔细看，原来问题出在这个 已用% 占用 100% 的 /dev/mapper/centos-root
# df -a文件系统 1K-块 已用 可用 已用% 挂载点.../dev/mapper/centos-root 52403200 52060036 343164 100% /.../dev/mapper/centos-home 147899844 32992 147866852 1% /home/dev/sda1 1038336 196772 841564 19% /boot...怎么办？因为我这是虚拟机，扩充容量很 easy ，从那个之前的 200G 扩展到了 500G ，这应该足够了！
但是，重启后再看，那个 100% 占用没有改变，因为 linux 扩展的磁盘不是直接就挂上的 -
冷静分析，找到对策
1). 设备 /dev/sda1 实际占用才 19% ，很空啊！
2). home 占用也很少， 才 1%
3). 原来 centos 给 root 用户才分配了 50G
4). 既然 home 那么空，干脆，将 root 下的大文件转移到 home说干就干！把那些大文件全部转移到了 /home ,再来查看
# df -h文件系统 容量 已用 可用 已用% 挂载点.../dev/mapper/centos-root 50G 29G 22G 58% //dev/mapper/centos-home 142G 21G 121G 15% /home/dev/sda1 1014M 193M 822M 19% /boot... -
OK ！ 可以继续了
如果啥时候 /home 也满了，就只能再挂载新的磁盘分区了
