最初使用的阿里云云盘只有50G 正常运行的hadoop集群突然无法正常运行了,web页面显示节点为UNHEALTHY 使用df -m命令,发现一些节点磁盘空间占用达到了99%,因此要扩容磁盘空间 1.为云盘建立快照,以防出错 2.磁盘扩容 3.选择扩容容量,选在线扩容,付费 4.如果是centos7 此处以CentOS 7操作系统为例演示分区扩展的步骤. 运行fdisk -l命令查看现有云盘大小. 以下示例返回云盘(/dev/vda)容量是100GiB.   [root@ecshost ~]#

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

原文:docker容器存放目录磁盘空间满了,转移数据修改Docker默认存储位置 版权声明:本文为博主原创文章,未经博主允许不得转载. https://blog.csdn.net/qq_37674858/article/details/79976751 今天在Liunx服务器上重启docker的时候,发现容器启动不了了,报的错误是:"ERROR:cannot  create temporary directory!".我的猜测应该就是磁盘空间满了,于是执行命令"df -h&q

oracle所在磁盘空间不足导致了数据库异常.需要减小数据文件的大小来解决. 1.检查数据文件的名称和编号 select file#,name from v$datafile; 2.看哪个数据文件所占的空间最大,根据该数据文件的编号查看该数据文件的最大数据块数 select max(block_id) from dba_extents where file_id=8; 查询结果 3.计算该表空间的实际占用空间.(不是物理文件的大小) 查看每个数据块的大小 show parameter db_bl

今天,在测试环境启动数据库时,报错: SQL> startup; ORACLE instance started. Total System Global Area  285212672 bytes Fixed Size     1218992 bytes Variable Size    75499088 bytes Database Buffers   205520896 bytes Redo Buffers     2973696 bytes Database mounted. ORA-1

因磁盘空间不足导致HDFS的NameNode进入安全模式问题记录,调用API上传及下载文件时报如下错误信息: org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.server.namenode.SafeModeException): Cannot delete /null/daxt/0265803074a54d54b8ec0b91df359bdf.log. Name node is in safe mode. Resource

很常见的一个问题 linux磁盘空间满了 但是没有大文件 解决思路: 1.用df 检查发现/根目录可用空间为0 [root@/]#df -h 2.用du检查发现各目录占用的空间都很少,有约3G的空间莫名其妙地丢了. [root@/]# du -m –max-depth=1|sort -gr 3.用lsof检查后才发现原因是,有文件被删除,而进程还活着,因而造成还占用空间的现象 [root@/]# lsof |grep delete 根据lsof列出的进程号,kill这些进程后,空间就释放出来了

问题描述:oracle服务器硬盘磁盘空间满了,没有空间写入数据: 解决思路: a.服务器是虚拟机还是实体机? 虚拟机,->物理机上有空间直接给它扩容,再给数据库的相关表空间添加文件就可: 实体机,->确定是否还有oracle收缩磁盘硬盘插槽,能新增物理硬盘,买+接入: b.删数据以及降低高水位: 通常思路是:找占用磁盘最大的表空间TS_1,找该表空间下巨大的表tableA,删除历史数据,降低高水位(table move),缩小表空间文件,腾出空间: 1.查询 表空间各文件 --找出占用磁盘最大

今天在使用exp imp将生产环境数据库导入到测试环境的过程中,imp的时候 发现在导入某张表的时候卡住了. 起初是以为该表比较大的缘故,后来过了很久 发现还是卡在那里. 最后分析原因 发现设置的归档目录大小太小了. 修改了归档目录的大小 Imp操作继续执行. 查看归档目录的大小 show parameter db_recovery_file_dest 修改归档目录的大小 alter system set db_recovery_file_dest_size=20G; 后来又遇到数据库表空间满了

1.RDS 数据日志已经快满了, 导致数据库不能写入,只读. 2. Binlog日志的保存及清理规则 MySQL实例的空间内默认清理binlog日志的规则如下: 实例空间内默认会保存最近18个小时内的binlog文件. 当实例使用空间小于购买空间的90%时,系统会保存购买空间的30%的binlog(即使该binlog文件已经上传到OSS内). 当实例使用空间超过购买空间的90%时,binlog会在上传到OSS后,发起删除本地数据的请求,但本地删除会有任务调度,有一定延迟. 3.Binlog文件上

在一次测试中,由于导入的数据量过大导致事务一直提交失败因为磁盘空间不够用了,一检查发现是undo表空间不够用,于是重新创建了一个表空间,准备把之前的undo表空间删除,删除时却发现一直删不掉,因为它一直在使用,于是关闭数据库,手动的删掉.然后重启数据库,于是乎各种问题来了 1 使用SYS 账号登录时报错:ORA-09817: Write to audit file failed 然后在使用df -h命令系统检查一下,发现Oracle安装目录所对应的磁盘空间已满,于是删除3天以前的trace文件,

block正常满 (磁盘实际不足)inode 满 大量的小文件block 满 文件没有被彻底删除(硬链接数0 进程调用数不为0) 解放方法: 1 查看df -h 磁盘使用量根据占用量大小逐步逐步排查 2 使用du -sh 查看大磁盘所有文件大小使用|grep G 过滤大文件数据 3 根据查找到的文件询问删除解决磁盘空间没满但是无法写入文件(inode用完了) 注意: # df -sh /* | grep G 查找到具体的文件或目录中,对此目录进行删除等操作,不能盲目的删除,要确定无用了,才能进行

先贴命令:du -m --max-depth=1或du -h --max-depth=1du:用于统计linux中文件或目录所占磁盘空间的大小du参数######-m:以M为单位展示查询结果-h:以K.M.G为单位展示查询结果,提高信息可读性--max-depth=1:其中,数字“1”是指查询结果中最多显示的目录层数,这里指最多显示一层目录 查看磁盘空间#df -mFilesystem                   1M-blocks  Used Available Use% Mounte

故障现象 2016.1.1号早上4点左右,zabbi数据库服务器报警,写入数据失败.登陆机器后检查发现磁盘空间使用95%没有用满,进去zabbix数据库,执行insert命令提示错误“errir 1030(HY000):got error 28 from storage engine”.    前提 zabbix数据库由于超大的写入量,我们使用tokudb存储引擎来存储,此引擎有强大的压缩比,写入性能也非常不错,适合zabbix数据库场景.   故障调查 1)检查错误日志,发现有如下 Versi

废话不多说直接上图 可以看得到 / 下面已使用100%,已经没有剩余空间可以使用了,上面跑的服务已经访问不了了. 接下来我就看看有没有垃圾文件可以清理的 du -sh * 由于这个机器比较特殊,上面有重要业务所以里面的任何东西都不能动.所以没有办法只能添加磁盘. 添加一块10G的磁盘,我的思路是既然东西不能动,而且aaa目录占用空间特别大所以,把aaa目录移到新挂载的磁盘上做一个软链接. 加完磁盘后,要重启才能生效哦. 现在看到已经出现我们刚添加的10GB的磁盘.没有任何分区,现在新建分区 然后

       同事求助, 他在删掉一个很大的文件后, 磁盘空间依旧没释放.上去一看, 果然 df 看到磁盘空间占用依旧是100%,等等 du 看了一把,磁盘空间剩余很大. 造成这个原因是因为进程依旧打开着删除的文件,而文件不存在与目录树中了,所有du统计的时候就不会统计就不会统计这个文件占用的空间了(而df 统计文件系统的总块数和剩余块数) 可以通过lsof查看具体是那个进程打开着这些被删除了的文件: lsof | grep delete 果然,他删掉的是mysql的慢日志, mysql依旧打开

上周五去某客户那里做数据库巡检.是window 2008系统上10g的一套NC系统的库,已经配置了DG,可是巡检时发现数据库报错: Tue Nov 11 10:13:57 2014 LNS: Standby redo logfile selected for thread 1 sequence 3945 for destination LOG_ARCHIVE_DEST_2 Tue Nov 11 10:14:29 2014 Errors in file d:\oracle\product\10.2

看了一下,有一个wtmp 和wtmp.1的文件非常大.wtmp记录的是机器注销.启动的信息.由此可见,机器长时间的不断重启,造成该日志记录超级大,把cf的空间给占满了. wtmp日志可以用who和last命令来看. who wtmp

日志文件在   /var/lib/docker/containers/<docker_container_id>/   目录下 查看日志大小 vim /opt/docker_log_size.sh #!/bin/sh echo "======== docker containers logs file size ========" logs=$(find /var/lib/docker/containers/ -name *-json.log) for log in $lo

df-h 看到根目录已经用满了! find / -size +100M |xargs ls -lh列出系统内大于100M的文件 du --max-depth=1 -h 查看当前目录内文件夹的大小 看一下才想起是内网开发用的数据库,里面最大的是备份目录 果不其然备份文件问题 使用排序命令从最大的开始删除效率更高 最后决定删除10天前的备份文件 rm -rf 010.tar rm -rf 011.tar 删除后的结果如下图 问题就解决了! 参考网址 https://blog.csdn.net/vio

大概是前俩天吧,发现公司的网站不定时的出现接口调不通的情况,便让手下小弟去服务器上查看一下,小弟告我磁盘空间满了,于是我让他处理一下.结果没想到他直接把 catlina.out 给干掉了.后果可想而知,磁盘空间还是一直是100%,无法使用,他还一脸蒙蔽.大概情况就是这样,下面说一下我解决的过程. 因为catlina.out 是tomcat 的输出日志,只要运行就会有日志输出,所有不能直接删除,要去清空.即当进程打开了某个文件时,只要该进程保持打开该文件,即使将其删除,它依然存在于磁盘中.这意味着