mysql 错误- 磁盘空间不足,

mysql 磁盘空间不足错误

  磁盘空间满了, 写不进去了。

141020 09:45:24 mysqld_safe Starting mysqld daemon with databases from /alidata/server/mysql-5.6.20/data
2014-10-20 09:45:24 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
2014-10-20 09:45:24 1606 [Note] Plugin ‘FEDERATED‘ is disabled.
2014-10-20 09:45:24 1606 [Note] InnoDB: Using atomics to ref count buffer pool pages
2014-10-20 09:45:24 1606 [Note] InnoDB: The InnoDB memory heap is disabled
2014-10-20 09:45:24 1606 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2014-10-20 09:45:24 1606 [Note] InnoDB: Memory barrier is not used
2014-10-20 09:45:24 1606 [Note] InnoDB: Compressed tables use zlib 1.2.3
2014-10-20 09:45:24 1606 [Note] InnoDB: Using CPU crc32 instructions
2014-10-20 09:45:24 1606 [Note] InnoDB: Initializing buffer pool, size = 128.0M
2014-10-20 09:45:24 1606 [Note] InnoDB: Completed initialization of buffer pool
2014-10-20 09:45:24 1606 [Note] InnoDB: Highest supported file format is Barracuda.
2014-10-20 09:45:24 1606 [Note] InnoDB: Log scan progressed past the checkpoint lsn 510100007
2014-10-20 09:45:24 1606 [Note] InnoDB: Database was not shutdown normally!
2014-10-20 09:45:24 1606 [Note] InnoDB: Starting crash recovery.
2014-10-20 09:45:24 1606 [Note] InnoDB: Reading tablespace information from the .ibd files...
2014-10-20 09:45:24 1606 [Note] InnoDB: Restoring possible half-written data pages
2014-10-20 09:45:24 1606 [Note] InnoDB: from the doublewrite buffer...
InnoDB: Doing recovery: scanned up to log sequence number 510107962
InnoDB: Transaction 3310511 was in the XA prepared state.
InnoDB: Transaction 3310511 was in the XA prepared state.
InnoDB: Transaction 3310547 was in the XA prepared state.
InnoDB: Transaction 3310547 was in the XA prepared state.
InnoDB: Transaction 3308073 was in the XA prepared state.
InnoDB: Transaction 3308073 was in the XA prepared state.
InnoDB: Transaction 3311321 was in the XA prepared state.
InnoDB: 4 transaction(s) which must be rolled back or cleaned up
InnoDB: in total 0 row operations to undo
InnoDB: Trx id counter is 3316992
2014-10-20 09:45:24 1606 [Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Last MySQL binlog file position 0 518283216, file name binlog.000003
InnoDB: Starting in background the rollback of uncommitted transactions
2014-10-20 09:45:25 7f1414c46700  InnoDB: Rollback of non-prepared transactions completed
2014-10-20 09:45:25 1606 [Note] InnoDB: 128 rollback segment(s) are active.
2014-10-20 09:45:25 1606 [Note] InnoDB: 5.6.20 started; log sequence number 510107962
2014-10-20 09:45:25 7f143e37a720  InnoDB: Starting recovery for XA transactions...
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction 3311321 in prepared state after recovery
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction contains changes to 1 rows
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction 3310547 in prepared state after recovery
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction contains changes to 4 rows
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction 3310511 in prepared state after recovery
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction contains changes to 4 rows
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction 3308073 in prepared state after recovery
2014-10-20 09:45:25 7f143e37a720  InnoDB: Transaction contains changes to 5 rows
2014-10-20 09:45:25 7f143e37a720  InnoDB: 4 transactions in prepared state after recovery
2014-10-20 09:45:25 1606 [Note] Found 4 prepared transaction(s) in InnoDB
2014-10-20 09:45:25 7f143e37a720 InnoDB: Error: Write to file ./test_szd/T_SD_AUCTION.ibd failed at offset 376832.
InnoDB: 16384 bytes should have been written, only -1 were written.
InnoDB: Operating system error number 28.
InnoDB: Check that your OS and file system support files of this size.
InnoDB: Check also that the disk is not full or a disk 141020 09:45:31 mysqld_safe mysqld from pid file /alidata/server/mysql-5.6.20/data/iZ23lt92evyZ.pid ended
时间: 2025-01-11 18:51:30

mysql 错误- 磁盘空间不足,的相关文章

二进制安装MySQL5.5.39,磁盘空间不足导致MySQL无法启动

--添加用户和组 [[email protected] local]# groupadd [[email protected] local]# useradd -g mysql -s /sbin/nologin -d /opt/msyql mysql --创建目录 [[email protected] local]# mkdir /data/mysql/mysql_3306/{data,logs,tmp} -p --做软链接到/usr/local/mysql [[email protected]

磁盘空间满了之后MySQL会怎样

大多数用户在对于磁盘进行分区的时候都是习惯性的不给系统盘预留很大空间,其实这并不是一个好习惯.因为系统分区并不像我们想象的那样会仅仅安装一个操作系统,系统分区多数还是会承载操作系统主要应用软件安装任务.那么当磁盘空间爆满后,MySQL会发生什么事呢?又应该怎么应对? 会发生什么事 当磁盘空间写满了之后,MySQL是无法再写入任何数据的,包括对表数据的写入,以及binlog.binlog-index等文件. 当然了,因为InnoDB是可以把脏数据先放在内存里,所以不会立刻表现出来无法写入,除非开启

磁盘空间不够导致mysql崩溃重启

起因: 群里有人提了句pt-ioprofile,我不知道,就查了查,想测一测,想以后可能会有帮助. 为了能看到效果,我选择了我虚拟机上最大的压测表Sbtest1,该表有100w数据,执行update sbtest1 set k=k+1; 并且通过pt-ioprofile查看到了想要的结果,然后就干别的去了,下午了,看update sbtest1 set k=k+1;这个窗口的光标还闪着,以为还没执行完,不停地回车,crtl c,各种不好用.过了一会儿,报错了,并且提示mysql已经重启了. 我去

提示如下错误:No space left ondevice,通过 df -h 查看磁盘空间,发现没满,请问可能原因是什么?

如果向磁盘写入数据提示如下错误:No space left ondevice,通过 df -h 查看磁盘空间,发现没 满,请问可能原因是什么? 1.1首先查看我们的磁盘剩余情况 [[email protected] /]# df -h                 #发现磁盘没有满  还有%47 Filesystem      Size  Used Avail Use% Mounted on /dev/sda3       6.9G  3.1G 3.5G  47% / tmpfs       

故障案例:磁盘空间不足可能引起的mysql问题

此前在工作中.由于客户的磁盘空间报警没怎么注意.空间不足引起了下面可能发生的mysql问题 1    mysql进程起不来 2    mysql无法正常关闭,必须kill -9 3    mysql能起来,可是用户连接失败.telnet  3306port不通 4    mysql能连接上,可是会堵塞大部分查询.比方能showprocesslist,可是select * frominformation_schema.processlist 时会报错:Incorrect key filefor t

MySQL ibdata1撑爆占满磁盘空间

MySQL主从由于ibdata1占满磁盘空间-->主从失效 因为设置了innodb_file_per_table = 1,ibdata1依旧撑爆占满磁盘空间 主从断的时候,IO线程在连接,SQL线程断掉. 想要了解为何ibdata1增长那么大? 个人这么理解的:主从断掉,IO线程在,获取到了事件事物的更新,而SQL线程断掉,导致产生大量的undo,撑爆了ibdata1. 最终验证发现,确实是undo占满了ibdata1. 下载一个小工具:py_innodb_page_info.py  本人网盘下

MySQL schema和binary log磁盘空间趋势分析

Author:Skate Time:2015/01/05 MySQL schema和binary log磁盘空间趋势分析 [[email protected] dist]# ./mysqlsize  --help usage: Database diskspace usage v0.1 ,(C) Copyright Skate 2014 [-h] [--load LOAD] --dbtype DBTYPE --cfg CFG --field FIELD --datadir DATADIR --l

sharepoint 2013 打开rdl报表,报表服务器数据库内出错。此错误可能是因连接失败、超时或数据库中磁盘空间不足而导致的

 最近在做reporting services报表的时候,部署到sharepoint后,打开rdl报表,经常遇到一个问题: 报表服务器数据库内出错.此错误可能是因连接失败.超时或数据库中磁盘空间不足而导致的. ---> Microsoft.ReportingServices.Diagnostics.Utilities.ReportServerStorageException: 报表服务器数据库内出错.此错误可能是因连接失败.超时或数据库中磁盘空间不足而导致的. ---> System.Da

MySQL删除数据几种情况以及是否释放磁盘空间【转】

MySQL删除数据几种情况以及是否释放磁盘空间: 1.drop table table_name 立刻释放磁盘空间 ,不管是 Innodb和MyISAM ; 2.truncate table table_name 立刻释放磁盘空间 ,不管是 Innodb和MyISAM .truncate table其实有点类似于drop table 然后creat,只不过这个create table 的过程做了优化,比如表结构文件之前已经有了等等.所以速度上应该是接近drop table的速度; 3.delet