服务器重启导致无法启动MySQL

温馨提示:必须要忘记rm命令


  今天服务器受到DDOS攻击,笔者脑残重启了一下服务器。结果造成MySQL服务器无法启动

mysql日志见下图。

160803 17:43:47 mysqld_safe Starting mysqld daemon with databases from /application/mysql/data
160803 17:43:47 [Note] /application/mysql/bin/mysqld (mysqld 5.5.49) starting as process 1975 ...
160803 17:43:47 [Warning] Using unique option prefix innodb_purge_thread instead of innodb-purge-threads is deprecated and will be removed in a future release. Please use the full name instead.
160803 17:43:47 [Note] Plugin 'FEDERATED' is disabled.
160803 17:43:47 InnoDB: The InnoDB memory heap is disabled
160803 17:43:47 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160803 17:43:47 InnoDB: Compressed tables use zlib 1.2.3
160803 17:43:47 InnoDB: Using Linux native AIO
160803 17:43:47 InnoDB: Initializing buffer pool, size = 64.0M
160803 17:43:47 InnoDB: Completed initialization of buffer pool
InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 7296 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 8192 pages, max 0 (relevant if non-zero) pages!
160803 17:43:47 InnoDB: Could not open or create data files.
160803 17:43:47 InnoDB: If you tried to add new data files, and it failed here,
160803 17:43:47 InnoDB: you should now edit innodb_data_file_path in my.cnf back
160803 17:43:47 InnoDB: to what it was, and remove the new ibdata files InnoDB created
160803 17:43:47 InnoDB: in this failed attempt. InnoDB only wrote those files full of
160803 17:43:47 InnoDB: zeros, but did not yet use them in any way. But be careful: do not
160803 17:43:47 InnoDB: remove old data files which contain your precious data!
160803 17:43:47 [ERROR] Plugin 'InnoDB' init function returned error.
160803 17:43:47 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160803 17:43:47 [ERROR] Unknown/unsupported storage engine: InnoDB
160803 17:43:47 [ERROR] Aborting

160803 17:43:47 [Note] /application/mysql/bin/mysqld: Shutdown complete

160803 17:43:47 mysqld_safe mysqld from pid file /application/mysql/data/www.pid ended

实际图片:

曾试过手动启动

启动命令为:mysqld_safe–defaults-file=/data/3306/my.cnf &

停止命令为:mysqladmin -u root -poldboy123 -S /data/3306/mysql.sockshutdown


但是发现一直提示没有pid,百度了一下有一篇文章说需要删除ib_logfile0和ib_logfile1两个文件

就可以启动,对这两个文件进行了一下科普,如下:

文章


mysql的innodb中事务日志ib_logfile

事务日志或称redo日志,在mysql中默认以ib_logfile0,ib_logfile1名称存在,可以手工修改参数,调节

开启几组日志来服务于当前mysql数据库,mysql采用顺序,循环写方式,每开启一个事务时,

会把一些相关信息记录事务日志中(记录对数据文件数据修改的物理位置或叫做偏移量);

作用:在系统崩溃重启时,作事务重做;在系统正常时,每次checkpoint时间点,会将之前写入事务

应用到数据文件中。

引入一个问题:在m/s环境中,innodb写完ib_logfile后,服务异常关闭,会不会主库能用ib_logfile恢复数据,而

binlog没写导致从库同步时少少这个事务?从而导致主从不一致;

redo日志写入方式:

1.ib_logfile写入当前事务更新数据,并标上事务准备trx_prepare

2.写入bin-log

3.ib_logfile当前事务提交提交trx_commit

恢复方式:

如果ib_logfile已经写入事务准备,那么在恢复过程中,会依据bin-log中该事务是否存在恢复数据。

假设:

1)结束后异常,因没有写入bin-log,从库不会同步这个事务,主库上,重启时,在恢复日志中这个

事务没有commit,即rollback这个事务.

2)结束后异常,这会bin-log已经写入,从库会同步这个事务。主库依据恢复日志和bin-log,也正常恢复此事务

综上描述:bin-log写入完成,主从会正常完成事务;bin-log没有写入,主从库rollback事务;不会出现主从库不一致问题.

相关参数(全局&静态):

innodb_log_buffer_size

innodb_log_file_size

innodb_log_files_in_group

innodb_log_group_home_dir

innodb_flush_log_at_trx_commit

innodb_log_buffer_size:事务日志缓存区,可设置1M~8M,默认8M,延迟事务日志写入磁盘,

把事务日志缓存区想象形如”漏斗”状,会不停向磁盘记录缓存的日志记录,而何时写入通过参数

innodb_flush_log_at_trx_commit控制,稍后解释,启用大的事务日志缓存,可以将完整运行大事

务日志,暂时存放在事务缓存区中,不必(事务提交前)写入磁盘保存,同时也起到节约磁盘空间占用;

innodb_log_file_size:控制事务日志ib_logfile的大小,范围5MB~4G;所有事务日志ib_logfile0+

ib_logfile1+..累加大小不能超过4G,事务日志大,checkpoint会少,节省磁盘IO,但是大的事务日

志意味着数据库crash时,恢复起来较慢.

引入问题:修改该参数大小,导致ib_logfile文件的大小和之前存在的文件大小不匹配

解决方式:在干净关闭数据库情况下,删除ib_logfile,而后重启数据库,会自行创建该文件;

innodb_log_files_in_group:DB中设置几组事务日志,默认是2;

innodb_log_group_home_dir:事务日志存放目录,不设置,ib_logfile0…存在在数据文件目录下

innodb_flush_log_at_trx_commit:控制事务日志何时写盘和刷盘,安全递增:0,2,1

事务缓存区:log_buffer;

0:每秒一次事务缓存区刷新到文件系统,同时文件系统到磁盘同步,但是事务提交时,不会触发log_buffer到文件系统同步;

2:每次事务提交时,会把事务缓存区日志刷新到文件系统中去,且每秒文件系统到磁盘同步;

1:每次事务提交时刷新到磁盘,最安全;

适用环境:

0:磁盘IO能力有限,安全方便较差,无复制或复制延迟可以接受,如日志性业务,mysql损坏丢失1s事务数据;

2:数据安全性有要求,可以丢失一点事务日志,复制延迟也可以接受,OS损坏时才可能丢失数据;

1:数据安全性要求非常高,且磁盘IO能力足够支持业务,如充值消费,敏感业务;

文章地址


由于经费原因,没有做CDN,所以扛不住DDOS攻击实属正常

下图是阿里云发监控:

网站流量监控

小结: 

防治DDOS的前提是必须要做好监控!

另外在受到攻击,重启服务器是没有作用的,在实际生产环境是不可以重启的。这点大家一定要冷静!


由于作者手残不小心rm -rf ib* 因为表示Innbodb表,所以导致所有数据全都被删除(已经哭晕在厕所)

 跟我一起忘记rm 命令把!!!!!!!!

ibdata用来储存文件的数据

而库名的文件夹里面的那些表文件只是结构而已


对于DDOS防范可以参考下面文章:

网站DDOS攻击防护实战老男孩经验心得分享

625某电商网站数据库宕机故障解决实录

http://oldboy.blog.51cto.com/2561410/1431161

http://oldboy.blog.51cto.com/2561410/1431172

关于MySQL引擎[innodb文章]

http://www.abcdocker.com/abcdocker/77

「点点赞赏,手留余香」

    还没有人赞赏,快来当第一个赞赏的人吧!
abcdocker运维博客
3 条回复 A 作者 M 管理员
  1. 内容很不错的,谢谢博主好心分享!票据宝-全国交易金额最大的票据理财平台,欢迎博主访问!
  2. […] ib_logfile1……..ib_logfilen 这个问题,在另一篇文章也有介绍 服务器重启导致无法启动MySQL 在此为大家解释一下: mysql的innodb中事务日志ib_logfile […]
  3. 票据宝-全国交易金额最大的票据理财平台怎么不理解啊
欢迎您,新朋友,感谢参与互动!欢迎您 {{author}},您在本站有{{commentsCount}}条评论
网站搭建
加入我们
  • 站长QQ:381493251一键联系
  • abcdocker 微信公众号
    abcdocker QQ群