#######################sample

【OIP - 互联网开放平台】在2019-07-28 21:30:11发生10.194.42.19 - - Linux上的监控项【磁盘空间】【Free disk space on /db/mysql】产生了异常: 【严重】: 空闲磁盘空间低于10%, /db/mysql. 当前值: 9.6740 【珠海华润银行】

原因：

在问题出现时,登录MySQL,执行show processlist查看是否存在异常SQL.

1.mysql -uroot --socket=/db/mysql/data/mysqltmp/mysql.sock -p

Enter password:

mysql> show processlist

-> ;

+-----+-------------+-----------+------+---------+----------+-----------------------------------------------------------------------------+------------------+

| Id  | User        | Host      | db   | Command | Time     | State                                                                       | Info             |

+-----+-------------+-----------+------+---------+----------+-----------------------------------------------------------------------------+------------------+

|   2 | system user |           | NULL | Connect | 24025479 | Waiting for master to send event                                            | NULL             |

3 rows in set (0.00 sec)

2. mysql慢查询日志

mysql> show variables like '%slow%';

+---------------------------+------------------------------------------+

| Variable_name             | Value                                    |

+---------------------------+------------------------------------------+

| log_slow_admin_statements | OFF                                      |

| log_slow_slave_statements | OFF                                      |

| slow_launch_time          | 2                                        |

| slow_query_log            | ON                                       |

| slow_query_log_file       | /db/mysql/data/mydata/mysql-slow.log |

+---------------------------+------------------------------------------+

mysql> show variables like '%long%';

| long_query_time                                        | 2.000000 |

慢查询时间为2s，

3.配置如下：

mysql> show variables like 'default_storage_engine';

+------------------------+--------+

| Variable_name          | Value  |

+------------------------+--------+

| default_storage_engine | InnoDB |

+------------------------+--------+

1 row in set (0.00 sec)

mysql> show variables like 'transaction_isolation';

Empty set (0.00 sec)

mysql> show variables like 'binlog_format';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| binlog_format | MIXED |

+---------------+-------+

1 row in set (0.00 sec)

mysql> show variables like 'binlog_cache_size';

+-------------------+---------+

| Variable_name     | Value   |

+-------------------+---------+

| binlog_cache_size | 2097152 |

+-------------------+---------+

1 row in set (0.00 sec)

mysql> show variables like 'max_binlog_cache_size';

+-----------------------+----------------------+

| Variable_name         | Value                |

+-----------------------+----------------------+

| max_binlog_cache_size | 18446744073709547520 |

+-----------------------+----------------------+

1 row in set (0.00 sec)

mysql> show variables like 'tmpdir';

+---------------+-------------------------------+

| Variable_name | Value                         |

+---------------+-------------------------------+

| tmpdir        | /db/mysql/data/mydata/tmp |

+---------------+-------------------------------+

1 row in set (0.00 sec)

mysql> show variables like 'transaction_isolation';

Empty set (0.00 sec)

4.查看数据库容量

mysql> select

-> table_schema as 'db',

-> sum(table_rows) as 'count',

-> sum(truncate(data_length/1024/1024, 2)) as 'data(MB)',

-> sum(truncate(index_length/1024/1024, 2)) as 'index(MB)'

-> from information_schema.tables

-> group by table_schema

-> order by sum(data_length) desc, sum(index_length) desc;

+--------------------+----------+----------+-----------+

| db                 | count    | data(MB) | index(MB) |

+--------------------+----------+----------+-----------+

| openapi            | 21915376 | 11710.97 |   1216.19 |

| mysql              |     2697 |     0.76 |      0.06 |

| information_schema |     NULL |     0.00 |      0.00 |

| performance_schema |    74026 |     0.00 |      0.00 |

+--------------------+----------+----------+-----------+

4 rows in set (1.28 sec)

mysql> select

-> table_schema as 'db',

-> table_name as 'table',

-> table_rows as 'count',

-> truncate(data_length/1024/1024, 2) as 'data(MB)',

-> truncate(index_length/1024/1024, 2) as 'index(MB)'

-> from information_schema.tables

-> order by data_length desc, index_length desc;

+--------------------+----------------------------------------------------+---------+----------+-----------+

| db                 | table                                              | count   | data(MB) | index(MB) |

+--------------------+----------------------------------------------------+---------+----------+-----------+

| openapi            | log_r_esb                                          | 5312774 |  1957.00 |      0.00 |

| openapi            | api_log_sys_0                                      | 2886067 |  1727.39 |    218.74 |

| openapi            | api_log_sys_6                                      | 2795942 |  1673.90 |    217.91 |

| openapi            | api_log_sys_5                                      | 2205103 |  1319.96 |    165.51 |

| openapi            | api_log_sys_2                                      | 2114416 |  1264.59 |    163.54 |

| openapi            | api_log_sys_3                                      | 2017041 |  1206.44 |    156.33 |

| openapi            | api_log_sys_4                                      | 1910052 |  1142.62 |    143.61 |

| openapi            | api_log_sys_1                                      | 1825220 |  1091.11 |    141.35 |

6.查看文件系统目录大小

[root@poipredis03 openapi]# du -s * |sort -nr

5971972 log_r_esb.ibd

1768856 api_log_sys_0.MYD

1714084 api_log_sys_6.MYD

1351648 api_log_sys_5.MYD

1294952 api_log_sys_2.MYD

1235412 api_log_sys_3.MYD

1179140 api_log_sys_1.MYD

1170056 api_log_sys_4.MYD

7．查看大表的engine

mysql> select table_catalog

->      ,table_schema

->     ,table_name

->    ,engine

->    from information_schema.tables

->    where table_schema='openapi' and table_name='log_r_esb';

+---------------+--------------+------------+--------+

| table_catalog | table_schema | table_name | engine |

+---------------+--------------+------------+--------+

| def           | openapi      | log_r_esb  | InnoDB |

+---------------+--------------+------------+--------+

1 row in set (0.27 sec)

可能是因为表碎片，删除了数据，OS文件并不会收缩，但是表的大小是会变小的。所以就造成了OS文件里有了碎片化空间。

解决思路：

1.建议找操作系统人员扩容该目录/db/mysql

##########################

MySQL查看数据库表容量大小

https://cloud.tencent.com/info/429e1f0cadbc960659e7a43232450ae0.html

【https://blog.csdn.net/fdipzone/article/details/80144166】

1.查看所有数据库容量大小

1

2

3

4

5

6

7

8

select

table_schema as '数据库'``,

sum(table_rows) as '记录数'``,

sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)'``,

sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)'

from information_schema.tables

group by table_schema

order by sum(data_length) desc, sum(index_length) desc;

2.查看所有数据库各表容量大小

1

2

3

4

5

6

7

8

select

table_schema as '数据库'``,

table_name as '表名'``,

table_rows as '记录数'``,

truncate(data_length/1024/1024, 2) as '数据容量(MB)'``,

truncate(index_length/1024/1024, 2) as '索引容量(MB)'

from information_schema.tables

order by data_length desc, index_length desc;

3.查看指定数据库容量大小

例：查看mysql库容量大小

1

2

3

4

5

6

7

select

table_schema as '数据库'``,

sum(table_rows) as '记录数'``,

sum(truncate(data_length/1024/1024, 2)) as '数据容量(MB)'``,

sum(truncate(index_length/1024/1024, 2)) as '索引容量(MB)'

from information_schema.tables

where table_schema=``'mysql'``;

4.查看指定数据库各表容量大小

例：查看mysql库各表容量大小

1

2

3

4

5

6

7

8

9

select

table_schema as '数据库'``,

table_name as '表名'``,

table_rows as '记录数'``,

truncate(data_length/1024/1024, 2) as '数据容量(MB)'``,

truncate(index_length/1024/1024, 2) as '索引容量(MB)'

from information_schema.tables

where table_schema=``'mysql'

order by data_length desc, index_length desc;

查询整个MySQL实例里面存储引擎为MyISAM的表

select table_catalog

      ,table_schema

      ,table_name

      ,engine

from information_schema.tables

where engine='MyISAM';

查询MyDB数据库里面存储引擎为MyISAM的表

select table_catalog

      ,table_schema

      ,table_name

      ,engine

from information_schema.tables

where table_schema='MyDB' and engine='MyISAM';

###########################

http://blog.chinaunix.net/uid-16728139-id-3495657.html

案例分享-MySQL服务器/tmp目录被占满

分类： Mysql/postgreSQL

2013-02-22 14:48:20

原文地址：案例分享-MySQL服务器/tmp目录被占满 作者：ning_lianjie

案例分享-MySQL服务器/tmp目录被占满

描述:

MySQL服务器在每天的22点/tmp目录磁盘空间被占满,持续10分钟左右,然后自动恢复./tmp目录大小10G,平时可用空间8G左右.MySQL版本 5.5

分析

1.       在问题出现时,进入/tmp目录,ls –al查看具体文件.

2.       在问题出现时,登录MySQL,执行show processlist查看是否存在异常SQL.

3.       查看MySQL慢查询日志.

4.       MySQL配置情况:

a)         default_storage_engine         = InnoDB

b)         transaction_isolation           = READ-COMMITTED

c)         binlog_format                 = mixed

d)         binlog_cache_size              = 32K

e)         max_binlog_cache_size         = 18446744073709547520

f)          tmpdir                       = /tmp

总结

1.       InnoDB存储引擎,在READ-COMMITTED事务隔离级别的情况下(默认的级别是REPEATABLE-READ),普通的DELETE操作,在记录binlog的时候,会采用ROW模式.(暂时还不清楚原因,以后分析).

2.       程序在每天的22点,有一个清理的定时任务.自动删除R表的数据,如下:

delete from R where time < xxx;

将某天之前的数据清除.但是该表比较大,近50G.

3.       MySQL参数

binlog_cache_size

max_binlog_cache_size

参考http://dev.mysql.com/doc/refman/5.5/en/replication-options-binary-log.html

4.       每次执行定时任务的时候,因为binlog记录的是ROW模式,再加上表的数据量比较大,binlog缓存一定会超过32K,结果就会在/tmp目录下生成临时文件(参考: When a thread that handles the transaction starts, it allocates a buffer of binlog_cache_size to buffer statements. If a statement is bigger than this, the thread opens a temporary file to store the transaction. The temporary file is deleted when the thread ends),MySQL默认配置,在64位系统情况下,binlog文件大小最大可以达到16EB.但是系统的/tmp目录是10G,所以事务执行一半,磁盘空间被占满,事务回滚.

5.       事后查看R表的数据以及binlog记录,验证了第4步的推论.

解决

在没有新数据写入的前提下,把确定保留的数据先放到新表里面,然后删除旧表,再把新表重命名.

create table R_20130220 select * FROM R where  time >= xxx;

DROP TABLE R;

RENAME TABLE R_20130220 TO R;

隔天观察nagios和cacti监控,故障恢复.

https://www.2cto.com/database/201303/192747.html

######### binglog 太大，导致磁盘空间太满了。

mysql开启BINGLOG后日志文件增长比较快，很快占满磁盘空间。

lrm929关注0人评论441人阅读2013-04-19 14:39:01

mysql开启BINGLOG后日志文件增长比较快，很快占满磁盘空间。

cd  /mysql/data/mydata

ls -ltr

-rw-rw---- 1 mysql mysql 1073742040 Jul 21 20:20 mysql-bin.000036
-rw-rw---- 1 mysql mysql 1073741977 Jul 23 21:33 mysql-bin.000037
-rw-rw---- 1 mysql mysql 1073742172 Jul 26 12:45 mysql-bin.000038
-rw-rw---- 1 mysql mysql 1073742485 Jul 28 10:45 mysql-bin.000039

通过以下几种方式删除日志文件：
**一、设置日志保留时长expire_logs_days自动删除
**查看当前日志保存天数：

show variables like '%expire_logs_days%';

这个默认是0，也就是logs不过期，可通过设置全局的参数，使他临时生效：

set global expire_logs_days=7;

设置了只保留7天BINLOG, 下次重启mysql这个参数默认会失败，所以需在my.cnf中设置

expire_logs_days = 7

**二、手动删除BINLOG (purge binary logs)
**用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件

PURGE {MASTER | BINARY} LOGS TO ‘log_name’
 PURGE {MASTER | BINARY} LOGS BEFORE ‘date’

例如：

PURGE MASTER LOGS TO ‘mysql-bin.010′;
PURGE MASTER LOGS BEFORE ‘2008-06-22 13:00:00′;
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 D

生产上有一个比较小的系统，发现mysql占用空间较大，经排查发现是binlog比较多引起的

查看binlog过期时间，设置的时间为90天，这个值默认是0天，也就是说不自动清理，可以根据生产情况修改，本例修改为7天

设置之后不会立即清除，触发条件是：

binlog大小超过max_binlog_size
手动执行flush logs
重新启动时(MySQL将会new一个新文件用于记录binlog)

我们执行flush logs;

如果binlog非常多，不要轻易设置改参数，有可能导致io争用，这时候可以使用purge命令予以清除:

将bin.000055之前的binlog清掉:

将指定时间之前的binlog清掉:

mysql 日志自动切换

感谢ATCO

有三种解决方法：1.关闭mysql主从，关闭binlog；2.开启mysql主从，设置expire_logs_days；3.手动清除binlog文件，> PURGE MASTER LOGS TO ‘MySQL-bin.010′;

实现：
1.关闭mysql主从，关闭binlog

# vim /etc/my.cnf //注释掉log-bin,binlog_format

Replication Master Server (default)

binary logging is required for replication

log-bin=mysql-bin

binary logging format - mixed recommended

binlog_format=mixed

然后重启数据库

2.重启mysql,开启mysql主从，设置expire_logs_days

# vim /etc/my.cnf //修改expire_logs_days,x是自动删除的天数，一般将x设置为短点，如10
expire_logs_days = x //二进制日志自动删除的天数。默认值为0,表示“没有自动删除”

此方法需要重启mysql，附录有关于expire_logs_days的英文说明

当然也可以不重启mysql,开启mysql主从，直接在mysql里设置expire_logs_days

> show binary logs;

show variables like '%log%';
set global expire_logs_days = 10;

3.手动清除binlog文件

# /usr/local/mysql/bin/mysql -u root -p

PURGE MASTER LOGS BEFORE DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY); //删除10天前的MySQL binlog日志,附录2有关于PURGE MASTER LOGS手动删除用法及示例
show master logs;

也可以重置master，删除所有binlog文件：

# /usr/local/mysql/bin/mysql -u root -p

reset master; //附录3有清除binlog时，对从mysql的影响说明

附录：
1.expire_logs_days英文说明
Where X is the number of days you’d like to keep them around. I would recommend 10, but this depends on how busy your MySQL server is and how fast these log files grow. Just make sure it is longer than the slowest slave takes to replicate the data from your master.
Just a side note: You know that you should do this anyway, but make sure you back up your mysql database. The binary log can be used to recover the database in certain situations; so having a backup ensures that if your database server does crash, you will be able to recover the data.

2.PURGE MASTER LOGS手动删除用法及示例,MASTER和BINARY是同义词

> PURGE {MASTER | BINARY} LOGS TO 'log_name'

PURGE {MASTER | BINARY} LOGS BEFORE 'date'

删除指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除MySQL BIN-LOG 日志，这样被给定的日志成为第一个。

实例：

> PURGE MASTER LOGS TO 'MySQL-bin.010'; //清除MySQL-bin.010日志

PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00'; //清除2008-06-22 13:00:00前binlog日志
PURGE MASTER LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY); //清除3天前binlog日志BEFORE，变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。

3.清除binlog时，对从mysql的影响
如果您有一个活性的从属服务器，该服务器当前正在读取您正在试图删除的日志之一，则本语句不会起作用，而是会失败，并伴随一个错误。不过，如果从属服务器是休止的，并且您碰巧清理了其想要读取的日志之一，则从属服务器启动后不能复制。当从属服务器正在复制时，本语句可以安全运行。您不需要停止它们。