msyql数据库受攻击处理思路

收到报错：

内存表'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的字段含义：

注释：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/