收到报错:
内存表'pvlogs' is full问题
11:36:31,088 WARN ~ SQL Error: 1114, SQLState: HY000
11:36:31,088 ERROR ~ The table 'pvlogs' is full
内存表大小受两个地方限制,内存表不能超过这两个值的任何一个。
1)创建表时指定的MAX_ROWS=1000000000
2)以及数据库参数,单位是byte,
MariaDB [log]> show VARIABLES like '%max_heap_table_size%';
+---------------------+-----------+
| Variable_name | Value |
+---------------------+-----------+
| max_heap_table_size | 671088640 |
转换成m,是640m,
注释通过查看表的对应的文件来判断表的大小:
mysql
innodb存储引擎的表对应的文件:
Innodb存储引擎可以使用共享表空间或独立表空间,所以分两种情况:
1)如果使用独立表空间,那么包含三个文件:数据和索引文件(.ibd)和存数据词典信息文件(.frm) 以及存储所有表结构的ibdata文件。
2)如果是共享表空间,那么包含两个文件:所有的表的数据和索引和表的结构保存在ibdata1文件,以及数据词典信息的.frm文件。
ibdata1、ibdata2等:系统表空间文件,存储InnoDB系统信息和用户数据库表数据和索引(前提使用的是共享表空间),所有表共用。
.ibd文件:单表表空间文件,每个表使用一个表空间文件(file per table),存放用户数据库表数据和索引(前提开启了使用独立表空间)。
开启使用独立表空间功能:
innodb_file_per_table加到配置文件中,也可以在variables中开启,如下代表开启了使用独立表空间:
mysql> show VARIABLES like '%innodb_file_per_table%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| innodb_file_per_table | ON |
+-----------------------+-------+
1 row in set (0.00 sec)
共享表空间是将所有的表的数据和索引保存在ibdata1中,这样的缺点是拷贝时必须拷贝整个大文件,而且删除表后容易产生碎片。
独立表空间是为每个表建立一个.ibd文件用来存储数据和索引,以及.frm用来存数据词典信息,这样,mysql就将innodb表的数据存入各自对应的.ibd文件中了,但结构等信息还是会写入ibdata。
innodb_file_per_table变量只能在配置文件里修改,不能使用set global
mysql
myisam存储引擎的表对应三个文件
:
数据文件(.MYD),索引文件(.MYI)和结构文件(.frm)
并且我们这里是
myisam存储引擎:如下三个文件相加等于表的大小:
[root@S243 log]# ll -ash
-rw-rw---- 1 mysql mysql 3.0K 12月 20 07:24 pvlogs_20161219.frm
-rw-rw---- 1 mysql mysql 172M 12月 20 07:24 pvlogs_20161219.MYD
-rw-rw---- 1 mysql mysql 178M 12月 20 07:24 pvlogs_20161219.MYI
-rw-rw---- 1 mysql mysql 3.0K 12月 21 07:24 pvlogs_20161220.frm
-rw-rw---- 1 mysql mysql 316M 12月 21 07:25 pvlogs_20161220.MYD
-rw-rw---- 1 mysql mysql 326M 12月 21 07:25 pvlogs_20161220.MYI
-rw-rw---- 1 mysql mysql 3.0K 12月 22 07:24 pvlogs_20161221.frm
-rw-rw---- 1 mysql mysql 317M 12月 22 07:25 pvlogs_20161221.MYD
-rw-rw---- 1 mysql mysql 326M 12月 22 07:25 pvlogs_20161221.MYI
-rw-rw---- 1 mysql mysql 3.0K 12月 23 07:24 pvlogs_20161222.frm
-rw-rw---- 1 mysql mysql 317M 12月 23 07:25 pvlogs_20161222.MYD
-rw-rw---- 1 mysql mysql 326M 12月 23 07:25 pvlogs_20161222.MYI
经查看从21号开始,pvlogs日志表大小超过了640m,因为收到报错 pvlogs' is full
临时解决办法:增大该参数
MariaDB [log]> set global max_heap_table_size=1271088640;
Query OK, 0 rows affected, 1 warning (0.00 sec)
按着正常业务发展,这个表为客户浏览量统计,增长速度很平滑,不会突然暴增的,这个表是不会到达640m
最近三天数据异常暴增:怀疑受攻击。
下面是这个表的statu的字段含义:
![](http://img.blog.itpub.net/blog/attachment/201612/26/29654823_1482717521454i.png?x-oss-process=style/bb)
注释:4 5 7 13 所有异常数量太多都有可能是受到恶意攻击,
经查看发现状态4和7 日志条数过多。
MariaDB [log]> select count(*),status from pvlogs_20161220 group by status;
+----------+--------+
| count(*) | status |
+----------+--------+
| 219243 | 0 |
| 103631 | 1 |
| 25 | 2 |
| 30 | 3 |
|
2308079 | 4 |
| 570913 | 5 |
|
965378 | 7 |
| 3470 | 8 |
| 4509 | 11 |
| 2898 | 13 |
+----------+--------+
10 rows in set (0.00 sec)
于是从针对异常的4和7展开
其中异常7的大部分是由某一个ip(2051504589 )产生
MariaDB [log]> select count(*),ip from pvlogs_20161220 where status=7 group by ip order by 1 ;
| 114 | 2637637462 |
| 117 | 676177698 |
| 136 | 676177750 |
|
962609 |
2051504589 |
+----------+------------+
其中异常4的大部分是由某一个ip(2051504589 )产生
MariaDB [log]> select count(*),ip from pvlogs_20161220 where status=4 group by ip order by 1 ;
| 30 | 712548434 |
| 34 | 676177698 |
| 38 | 676177750 |
| 44 | 2637637462 |
|
2306638 | 2051504589 |
+----------+------------+
ip转换(行业标准,记住语句即可):
MariaDB [log]> select inet_aton('127.0.0.1'),inet_aton('255.255.255.255'),inet_ntoa(2051504589)
-> ;
+------------------------+------------------------------+-----------------------+
| inet_aton('127.0.0.1') | inet_aton('255.255.255.255') | inet_ntoa(2051504589) |
+------------------------+------------------------------+-----------------------+
| 2130706433 | 4294967295 |
122.71.121.205 |
+------------------------+------------------------------+-----------------------+
并且21和22都是这个ip在攻击
22号
4 | 1571447 | 2051504589 |
7 | 2088830 | 2051504589 |
21号
4 | 1784638 | 2051504589 |
7 | 1755871 | 2051504589 |
23号出现另一个ip
122.71.123.5
共发现两个攻击ip: 122.71.123.5 和
122.71.121.205 已经报告给三哥处理 ,
总结:当发现目录空间或者是内存表的大小都受到限制的时候,第一反应就是马上扩容和扩大受限制的参数,很快就会解决问题,但是回过头来一定要去考虑,这里的突然full是否是正常的,一定要结合业务分析,否则您的解决办法只是临时的,要从根源处解决。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/29654823/viewspace-2131361/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/29654823/viewspace-2131361/