MYSQL No space left on device

1、导入sql文件时mysql 挂了,查看原因为:

2018-08-10T07:26:18.310074Z 1083 [ERROR] InnoDB: Write to file ./everdata_knowledge/cell_v201601.ibdfailed at offset 1318060032, 1048576 bytes should have been written, only 643072 were written. Operating system error number 28. Check that your OS and file system support files of this size. Check also that the disk is not full or a disk quota exceeded.
2018-08-10T07:26:18.310121Z 1083 [ERROR] InnoDB: Error number 28 means 'No space left on device'

2、发现问题为没有磁盘空间;

查看系统磁盘:

[root@dmp8 log]# df -h
Filesystem           Size  Used Avail Use% Mounted on
/dev/mapper/cl-root   50G   50G  30k  100% /
devtmpfs              63G     0   63G   0% /dev
tmpfs                 63G     0   63G   0% /dev/shm
tmpfs                 63G   18M   63G   1% /run
tmpfs                 63G     0   63G   0% /sys/fs/cgroup
/dev/sdc             3.6T   94M  3.4T   1% /data2
/dev/sdb             3.6T  338M  3.4T   1% /data1
/dev/sda2           1014M  139M  876M  14% /boot
/dev/mapper/cl-home  3.5T  175G  3.1T   6% /home
tmpfs                 13G     0   13G   0% /run/user/0

3、查看mysql 存储数据目录:

[root@dmp8 log]# find /  -name *.MYD 
/var/lib/mysql/mysql/db.MYD
/var/lib/mysql/mysql/user.MYD
/var/lib/mysql/mysql/func.MYD
/var/lib/mysql/mysql/tables_priv.MYD
/var/lib/mysql/mysql/columns_priv.MYD
/var/lib/mysql/mysql/proc.MYD
/var/lib/mysql/mysql/procs_priv.MYD
/var/lib/mysql/mysql/event.MYD
/var/lib/mysql/mysql/ndb_binlog_index.MYD
/var/lib/mysql/mysql/proxies_priv.MYD
/var/lib/mysql/ever_ta/sys_user_group.MYD
/var/lib/mysql/ever_ta/ea_ball_day.MYD
/var/lib/mysql/ever_ta/sys_user_group_authority.MYD
/var/lib/mysql/ever_ta/ea_log_show.MYD
/var/lib/mysql/ever_ta/user.MYD
/var/lib/mysql/ever_ta/user_role.MYD
/var/lib/mysql/ever_ta/ea_log_click.MYD
/var/lib/mysql/ever_ta/ea_ball_day_city.MYD
/var/lib/mysql/ever_ta/role.MYD
/var/lib/mysql/ever_ta/sys_config.MYD
/var/lib/mysql/ever_ta/ea_ball_h_city.MYD
/var/lib/mysql/ever_ta/regularconfig.MYD
/var/lib/mysql/ever_ta/ea_ggsn_day.MYD
/var/lib/mysql/ever_ta/ea_ball_h.MYD
/var/lib/mysql/ever_ta/ea_channel_h.MYD
/var/lib/mysql/ever_ta/ea_channel_day.MYD
/var/lib/mysql/ever_ta/ea_ggsn_status_h.MYD
/var/lib/mysql/ever_ta/ea_log_visit_detail.MYD
/var/lib/mysql/ever_ta/ea_ggsn_h.MYD
/var/lib/mysql/ever_ta/ea_ball_show_day_type.MYD
/var/lib/mysql/ever_ta/ea_ball_click_day_type.MYD
/var/lib/mysql/ever_ta/ea_ball_show_h_type.MYD
/var/lib/mysql/ever_ta/ea_ball_click_h_type.MYD
/var/lib/mysql/ever_ta/everta_ad.MYD

4、查看文件大小:

[root@dmp8 mysql]# du -sh *
4.0K    auto.cnf
9.1M    everdmp
112K    eversunshine
23M     ever_ta
123M    hive
4.0K    ib_buffer_pool
76M     ibdata1
48M     ib_logfile0
48M     ib_logfile1
12M     ibtmp1
12M     mysql
0       mysql.sock
4.0K    mysql.sock.lock
1.1M    performance_schema
676K    sys
1.2G    everdata_knowledge

5、结论:确实是系统磁盘满了;(磁盘根目录根本找不到占用空间的文件,所以才初次下策,删除自己导入的大的数据库,如果根目录磁盘能找到大的不用的文件,直接删除,重启mysql即可;)删除了everdata_knowledge数据库;

6、重新启动mysql,报错找不到everdata_knowledge的表了;

2018-08-10T09:06:29.398083Z 0 [ERROR] InnoDB: Tablespace 2501 was not found at ./everdata_knowledge/crawler_imei_imeidb.ibd.
2018-08-10T09:06:29.398093Z 0 [ERROR] InnoDB: Set innodb_force_recovery=1 to ignore this and to permanently lose all changes to the tablespace.
2018-08-10T09:06:29.398100Z 0 [ERROR] InnoDB: Tablespace 2502 was not found at ./everdata_knowledge/crawler_vendor.ibd.
2018-08-10T09:06:29.398591Z 0 [ERROR] InnoDB: Cannot continue operation.

7、被迫在/etc/my.cnf 中设置:innodb_force_recovery=6;

    因为日志已经损坏,这里采用非常规手段,首先修改innodb_force_recovery参数,使mysqld跳过恢复步骤,将mysqld 启动,将数据导出来然后重建数据库。

innodb_force_recovery可以设置为1-6,大的数字包含前面所有数字的影响。

  1. (SRV_FORCE_IGNORE_CORRUPT):忽略检查到的corrupt页。
  2. (SRV_FORCE_NO_BACKGROUND):阻止主线程的运行,如主线程需要执行full purge操作,会导致crash。
  3. (SRV_FORCE_NO_TRX_UNDO):不执行事务回滚操作。
  4. (SRV_FORCE_NO_IBUF_MERGE):不执行插入缓冲的合并操作。
  5. (SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志,InnoDB存储引擎会将未提交的事务视为已提交。
  6. (SRV_FORCE_NO_LOG_REDO):不执行前滚的操作。

注意

  a 当设置参数值大于0后,可以对表进行select,create,drop操作,但insert,update或者delete这类操作是不允许的。

8、能正常查询等操作;导出数据库再重建;

### Windows Docker Desktop 加载 MySQL 镜像时磁盘空间不足解决方案 #### 一、检查并清理现有资源 对于“no space left on device”的错误提示,在Docker中启动容器失败可能是因为宿主机上的可用存储空间不足以创建新的AUFS挂载点[^2]。因此,应当先确认当前系统的剩余容量情况。 可以通过命令`docker system df`来查看各个卷、镜像和容器占用的空间大小;利用`docker images ls`列出所有本地存在的镜像文件以便识别不再使用的项目进行删除操作以释放更多位置给新实例使用。 如果存在大量未被充分利用或者已经停止运作的服务进程,则可以考虑通过执行`docker rm $(docker ps -a -q)`移除这些无用实体从而腾出宝贵的数据区段供后续部署任务调用。 另外,定期清除悬空(dangling)的镜像是保持工作环境整洁的好习惯之一,这可通过下面这条指令完成: ```bash docker rmi $(docker images -f "dangling=true" -q) ``` #### 二、调整默认存储路径或增加分配额度 有时即使进行了上述优化措施之后仍然无法满足需求,这时就需要思考改变默认保存数据的位置或者是扩大分区本身的尺寸了。 - **更改默认存储目录**:可以在安装前指定不同的根目录作为Docker守护程序的工作区域,比如将其迁移到具有更大容量的驱动器上。具体做法是在服务启动参数里加入类似这样的选项`--data-root="E:\docker-data"`(假设目标盘符为E:)。 - **扩展虚拟硬盘(VHD)**:如果是采用Hyper-V后端引擎的话,那么还可以尝试增大关联于该应用软件包所依赖的基础映像(.vhdx)的实际物理长度。此过程涉及到编辑注册表键值以及手动修改XML描述文档等内容,相对复杂一些但确实可行有效。 #### 三、设置合理的交换机制 适当启用Swap功能有助于缓解因RAM紧张而导致的整体性能下降现象,尤其是在运行大型应用程序期间更是如此。虽然这不是直接针对磁盘满溢状况提出的建议,但在某些情况下却能间接起到辅助作用。 需要注意的是,过度依赖swap可能会带来额外开销进而影响效率表现,所以要谨慎权衡利弊得失后再做决定。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值