背景
由云上的一个服务返回异样触发的，因为最近服务代码未有改变，之前运行失常，所以首先到服务所在的服务器查看服务的状态：
[root@manager-01 ~]# systemctl status <service-name>Jul 27 17:51:09 manager-01 node[14705]: { Error: ENOSPC: no space left on device, write errno: -28, code: 'ENOSPC', syscall: 'write' }Jul 27 17:51:11 manager-01 node[14705]: { Error: ENOSPC: no space left on device, write errno: -28, code: 'ENOSPC', syscall: 'write' }Jul 27 17:51:21 manager-01 node[14705]: { Error: ENOSPC: no space left on device, write errno: -28, code: 'ENOSPC', syscall: 'write' }能够发现报错信息很明确：空间有余，无奈写入
备注：OS版本是：CentOS 7
定位
首先查看下以后服务器空间应用状况：
[root@manager-01 ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 40G 38G 0 100% /devtmpfs 1.9G 0 1.9G 0% /devtmpfs 1.9G 0 1.9G 0% /dev/shmtmpfs 1.9G 384K 1.9G 1% /runtmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup/dev/mapper/vg00-data 100G 33M 100G 1% /datatmpfs 380M 0 380M 0% /run/user/1000发现根目录/曾经没有可用空间了
查看下是哪些目录空间用的最多，逐渐排查：
[root@manager-01 /]# sudo du -s -h /* | sort -nr798M /home384K /run372M /app143M /boot59M /etc40K /tmp35G /var26M /root16K /lost+found4.0K /srv4.0K /opt4.0K /mnt4.0K /media1.7G /usr......能够发现/var目录应用了35G，占了87.5%的空间，依照上述办法逐渐排查，最终发现：
[root@manager-01 mysql]# du -s -h ./* | sort -nr1004K ./mysql212K ./performance_schema92K ./Alerts_DB28G ./ibdata116K ./aria_log.000000015.0M ./ib_logfile15.0M ./ib_logfile04.0K ./test4.0K ./aria_log_control0 ./mysql.sock在/var/lib/mysql目录下发现一个超大文件ibdata1，一个文件28G
百度下这个文件是何许内容：ibdata1文件是InnoDB存储引擎的共享表空间文件
该文件中次要存储着上面这些数据：
- data dictionary
- double write buffer
- insert buffer/change buffer
- rollback segments
- undo space
- Foreign key constraint system tables
参考链接：
https://mp.weixin.qq.com/s/KD2qLrmWY80yFxUtxJVNMA
解决方案
既然定位出是mysql的共享表空间文件增大导致的零碎空间被耗完，那么就寻找解决方案吧，摸索过程都是百度各种解决方案，而后再虚机模仿操作，这里间接给出解决办法：
1、批改共享表空间为各表独立空间
这个计划网上有许多案例，这里给出本人的操作过程，供参考
数据库版本：
[t3mgr@manager-01 ~]$ mysql --versionmysql Ver 15.1 Distrib 5.5.65-MariaDB, for Linux (x86_64) using readline 5.1我这里用的是mariadb 5.5.65版本
- 进行本人的业务，避免过程中有数据操作（我这是服务根本不可用了，所以没有影响，此处操作请依据本人理论状况判断）
systemctl stop <service-name>- 备份数据库（全库）
[root@manager /]# mysqldump -uroot -p<password> --all-databases --add-drop-table > /data/db_backup.sql<password>为参数，实际操作请输出对应的明码
/data/db_backup.sql为备份的文件名，依据理论状况找个足够大的空间搁置（大于原有mysql目录占用的空间必定就足够了）
如果备份内容较大，可能会破费肯定工夫，要急躁期待...
- 批改mysql（mariadb）配置
配置文件个别为/etc/my.cnf
在[mysqld]下减少上面配置
innodb_file_per_table=1
- 验证批改是否失效
先将mysql(mariadb)启动
[root@manager /]# systemctl restart mariadb而后进入mysql视图执行查看变量的命令：show variables like '%per_table%';
#mysql -uroot -p<password>mysql> show variables like '%per_table%';+-----------------------+-------+| Variable_name | Value |+-----------------------+-------+| innodb_file_per_table | ON |+-----------------------+-------+1 row in set (0.00 sec)如果对应的值为ON，则示意批改胜利。
- 删除原来的数据库文件
在/var/lib/mysql目录下执行如下命令
[root@manager-01 mysql]# rm -rf ibdata1[root@manager-01 mysql]# rm -rf ib_logfile*[root@manager-01 mysql]# rm -rf <db-name><db-name>为本人的数据库名称
- 还原数据库
[root@daik-manager /]# mysql -uroot -p<password> < /data/db_backup.sql数据库较大时，这个步骤也会耗时，请期待...
通过以上几步后，能够看到新的ibdata1文件就只有几十M了，数据及索引都变成了针对单个表的小ibd文件了，它们在相应数据库的文件夹上面
难堪的是，操作了这么半天，再查看下空间状况，腾挪出了3G空间，还是无济于事啊，没方法，持续想辙
2、将数据库挪到其余地位
这个办法次要是将mysql挪到别的有空间的目录，能够依据本人的理论状况，看哪个目录的挂载空间够大，就挪到哪去，这次要还是因为服务部署太随便，没有将mysql布局好，导致空间有余。
- 进行服务，同上
- 进行数据库，将mysql目录整体搬迁
[root@manager-01 mysql]#mv /var/lib/mysql /data或者用如下办法迁徙
rsync -avz /var/lib/mysql /data/ rsync 罢黜迁徙目标目录的目录属主及权限等操作
- 批改配置文件/etc/my.cnf
[mysqld]innodb_file_per_table=1#datadir=/var/lib/mysql#socket=/var/lib/mysql/mysql.sockdatadir=/data/mysqlsocket=/data/mysql/mysql.sock- 创立软连贯
[root@manager-01 mysql]#ln -s /data/mysql /var/lib/mysql - 给目录赋予权限
[root@manager-01 mysql]#chown -R mysql.mysql /home/mysql/数据库搬迁后，如果用户组和用户名都是mysql，则不必执行此步骤也能够。
- 重启数据库
[root@manager-01 mysql]#systemctl restart mariadb至此，才将数据库胜利搬迁地位，给系统目录腾出空间：
[root@manager-01 ~]# df -hFilesystem Size Used Avail Use% Mounted on/dev/vda1 40G 8.9G 29G 24% /devtmpfs 1.9G 0 1.9G 0% /devtmpfs 1.9G 0 1.9G 0% /dev/shmtmpfs 1.9G 384K 1.9G 1% /runtmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup/dev/mapper/vg00-data 100G 42G 59G 42% /datatmpfs 380M 0 380M 0% /run/user/1000